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(57) Abstract 

A technique for effecting electronic commerce using a data network Is described. The data networic includes a plurality of subsystems 
which, together, form on integrated system for receiving customer order* for selected items via a data network, fulfilling the customer 
orders, and delivering the ordered products to the customers. Moreover, according to a specific embodiment, the integrated nature of the 
system architecture of the present invention allows the on-line merchant to provide a guarantee to the customer that the ordered Items will 
be available to be delivered to the customer at the specified delivery date, time, and location. 
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INTEGRATED SYSTEM FOR ORDERING, FULFILLMENT, AND DELIVERY 
OF CONSUMER PRODUCTS USING A DATA NETWORK 


BACKGROUND OF THE INVRN^ipN 
Field of the Invention 

This invention relates to the field of electronic commerce. In particular, the 
invention relates to a technique for selling and delivering consumer products to 
customers using a data network. 

Description of the Related Art 

Companies have been delivering goods to customer homes for years using 

15 many different kinds of delivery systems. Examples run from mail order catalog 
shopping to on-line ordering and delivery services such as those provided by 
Amazon.com and Peapod.com. Indeed, the demand for home shopping and home 
delivery is increasing. However, many of the conventional systems which provide 
home shopping and home delivery services have significant limitations that prevent 

20 their adoption on a large scale basis. 

For example, the on-line grocery delivery service provided by Peapod.com 
(implemented by Peapod, Inc.) allows customers to access an on-line grocery store to 
place grocery orders. "Shoppers" (i.e. employees of Peapod) fill the orders by 
traveling to local grocery stores and purchasing the groceries ordered by the 

25 customers. The groceries are then delivered to the customer's home. In order to make 
a profit on the transaction, Peapod adds delivery charges on to the grocery bill. This 
makes the groceries more expensive than if the customer had performed the shopping 
and purchasing himself/herself. 

Additionally, when a customer places an order, Peapod can not guarantee that 

30 the ordered item will be available to be delivered to the customer. Thus, if the 
grocery store does not have the ordered item (e.g, out of stock), the "shopper" cannot 
deliver that item to the customer. 
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Further, delivery scheduling problems may also arise with on-line shopping 

dehvery ^uest for an order to be deliver* on the same day that the order was 
Placed. Wore.manyshoppingservicesdonotofferthisfeature. AdditionaUy it 
order took too long to fulfill by the "shopper". 

In addition to the Pcapod technique, the* are other conventional on-line 
techniques which allow a customer to purchase customer products via the Internet, 

example, on-line retailers such as Amazon.com, he. provide the ability for a 
customer to select and purchase various products via the Internet or World Wide 
Web. Using conventional techniques, an on-line product purchasing transaction will 
typically include the following steps. 

First, the customer selects one or more products to be purchased. Once the 
customer has finished selecting the desired produces), the customer may men proceed 
to a check-out or order confirmation page. During the check-out or order 
confirmation process, the customer provides the necessary information for completing 
the transaction purchase, such as. for example, the customer's name, credit card 
number, shipping address, etc. Before the order is confirmed by the on-line retailer 
(e.g.. Amazon.com), the billing and financial information is verified and processed' 
For example, if a credit card is used by the customer to purchase selected on-line 
products, a credit card transaction for the total amount of the purchase will be 
authonzed before the purchase order is confirmed and fulfilled by the merchant 
Once the paymen t transaction has been authorized, the on-line merchant typically 
fulfills the order by obtaining the purchased products, and shipping the purchased 
products the customer's shipping address using a common carrier (e.g. third-party 
courier) such as, for example, UPS, USPS, Federal Express, etc. ^ customer's 
credit card is typically billed at the time of shipment. 

Although the above-described on-line product purchasing technique provides 
the convenience of allowing a customer to purchase and receive a desired product 
without having to venture outside his or her home, current on-line shopping 
techniques suffer from a number of additional disadvantages (in addition to those 
described previously). For example, many on-line merchants provide adequate 


customer service relating to on-line product purchases, but typically provide 
inadequate customer service for handling returns or customer complaints. Further, 
once the customer's order has been processed, a customer typically does not have the 
ability to change, alter, or cancel the order. Rather, the customer must typically wait 
5 until he or she receives the originally ordered goods, and then must make a 
subsequent request to the on-line merchant for returning or modifying at least a part of 
the order. This latter request is typically handled as a separate transaction on the 
merchant's side, and may involve lengthy delays. Additionally, if the customer 
wishes to return one or more products, the customer is typically required by the 

10 merchant to first obtain a return authorization number (after first submitting a return 
request), and typically is responsible for paying shipping costs for shipping the 
returned products back to the merchant. 

The following example may help to illustrate some of the potential problems 
which a customer may encounter when purchasing products via on-line retailers or 

15 merchants. First, let us assume that a customer has selected two books for purchase 
using an on-line merchant, such as, for example, Amazon.com. When the customer 
J proceeds to the check-out page, the customer authorizes a total amount (i.e., for the 

books, tax, and shipping) to be billed to his or her credit card. Once the credit card 
authorization for the total amount has been received, the merchant fulfills the order 

20 and forwards the order to a common carrier for shipment. The customer's credit 
account will be billed at this time for the total amount specified above. 

After the order has been fulfilled by the merchant, the customer is typically 
unable to modify or cancel the order. Thus, for example, if the customer subsequently 
wishes to cancel one of the ordered books after the merchant has fulfilled the order, 

25 the customer must first wait to receive the book, and then submit a separate request to 
the on-line merchant for returning the book. It is worth noting that since the 
purchased items are typically shipped using an independent courier service or 
common carrier such as UPS, Federal Express, or the U.S. postal service, there is no 
mechanism in place whereby the customer is able to return the undesired product 

30 (e.g., book) back to the delivery courier for an immediate refund. Rather, as is 
typically the case, the customer must first obtain a return authorization number from 
the merchant, re-package the unwanted product, and ship the unwanted product back 


3 


10 


WO 00/68859 

PCTAJS00/13038 

» to MM. I*** UK «w it ^ „, fc 

■ssurf » fc customer u*,, ,.„, praIffi!t „„ ^ ^ 

«to* h to —H. *h . ^ ^ m>y oppg^ gg . refund or a 
credit on the customer's credit card account 

An additional problem with convention,, on-line purchasing transacUons 

^SSSSSSSS» «*— P^whenamerchantreceivesarequest 
for a product return, me merchant is not able to include the returned product as part of 
the merchant's current inventory until the returned product is physically received at 
the merchant's site and the return processed, which may take up to 4 to 6 weeks 
Moreover, until the returned order is processed, the returned merchandise wil, 
typ.ca.lv not be included as part of the inventory made available for customer 
15 purchase. This results in an inefficient allocation of resources. 

In Ught of the above, there exists a continual need to improve upon electronic 
commerce and on-line purchasing techniques. 

SUMMARY OF THE INVFrVTinm 
According to specific embodiments of the present invention, a technique for 
effecting electronic commerce using a data network is described. The data network 
includes a plurality of subsystems which, together, form an integrated system for 
recemng customer orders for selected items via a data network, fulfilling the 
customer orders, and delivering the ordered products to the customers. Moreover 
according to a specific embodiment, the integrated nature of the system architecture 
of the present invention allows the on-line merchant to provide a guarantee to the 
customer that the ordered items will be available to be delivered to the customer at the 
specified window delivery time. 

According to a specific embodiment, an integrated system is disclosed for 
effecung electronic commerce via a data network. The system comprises an 
inventory subsystem comprising memory. The inventory subsystem includes an 
mventory database configured or designed to maintain inventory records of a plurality 
of , terns of merchandise. The system also includes a customer interface subsystem in 
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communication with the inventory subsystem. The customer interface subsystem is 
configured or designed to store available inventory information, and is also 
configured or designed to present selected item informatio n relating to the inventory 
merchandise to at least one customer via the data network. The customer interface 
5 subsystem is further configured or designed to facilitate customer shopping 
transactions, and to store customer order information.. The integrated system also 
comprises an Order Fulfillment Subsystem in communication with the inventory 
subsystem. The Order Fulfillment Subsystem is configured or designed to receive 
customer order information captured by the customer interface subsystem. TOe order 
10 information includes at least one customer order for at least one item. The Order 
Fulfillment Subsystem is also configured or designed to facilitate fulfillment of the 
customer order. In a specific embodiment, fulfillment of a customer order includes 
obtaining at least a portion of the items relating to the order and preparing the 
obtained items for shipment to the customer. Additionally, the integrated system 

15 includes the delivery subsystem in communication with the customer interface 
subsystem and the inventory subsystem. The delivery subsystem is configured or 
-a designed to receive items relating to at least one fulfilled customer order, and is also 

configured or designed to facilitate delivery of the received items to the customer. 

An additional aspect of the above embodiment provides that the system 

20 further comprises a Publishing Subsystem in communication with the inventory 
subsystem and the customer interface subsystem for managing item and catalog data 
associated with a plurality of items of merchandise. Another aspect of this 
embodiment provides that the customer interface subsystem comprises a capacity 
database for managing capacity data associated with each of the plurality of 

25 subsystems. According to one embod iment, the capacity data includes faabl T 
capacity data for each subsystem and /reserved [capacity 4ata for each subsy stem 
wherein the reserved capacity data is related to placed customer orders which have' 
not yet been delivered to the customer. The customer interface subsystem may also 
be configured or designed to manage the inflow of customer orders at the time of 

30 ordering, using the capacity data. 

An alternate embodiment of the present invention is directed to a method for 
effecting electronic commerce via a data network. The data network comprises a 
customer interface subsystem for facilitating ordering transactions of items selected 
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by at least one customer; an Order Management Subsystem for managing customer 
slT f * f 7* mm0ty 8t0Ck - S — ** - ^ 
fccuUatmg dehve* 0 f customer orders to the customer, A ZJZX 
5 reccved a, the customer mterface subsystem . jhe customer order JLI 

0 £ IT" T CUSt0mer ^ ^ " 46 ^ Fu,Sltaent Su ^iem. 
0 The fulfilhng of an order includes verifying each inventory item which ha, been 

successfully fulfilled and processed for shipment to the customer. Tt* delivery 
subsystem is then used to deliver the fulfilled order items to me customer At the 
tune 0 f the delivery of the f u ,fi„cd order to the customer, a record is generated of 
each ncm being received by the customer. After the order has been delivered to the 
customer, the customer is then billed for the order. An additional aspect of this 
embodiment provides that the customer is able to modify the customer order at the 
tune of delivery of the order to the customer. In a specific embodiment, the 
mediation of a customer order which is iniUated during delivery of the order to the 
customer may be processed by the delivery courier using a mobile field device which 
has been configured or designed to process and store customer order data. 
Additionally, using the mobile field device, the delivery courier may process, at the 
fme of delivery, other customer service requests such as, for example, customer 
returns, credits, or other adjustments. 

An alternate embodiment of the present invention is directed to an integrated 
> architecture system for effecting electronic commerce via a data network. Tne system 
composes a customer interface subsystem for presenting representations of selected 
products to customers via the data network. The customer interface subsystem is also 
configured to enable customers to generate orders for any of me selected products via 
the data network. The system further comprises an inventory subsystem in 
» conTmunicationwiththecustomerinterfacesubsystera. The inventory subsystem may 
be configured to maintain and control inventory data related to products presented to 
the customers. The system may further comprise an order fulfillment subsystem in 
communication with the inventory subsystem, which is configured to process 
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customer orders via the data network. The system may further comprise a 
transportation subsystem in communication with the customer interface subsystem 
and order fulfillment subsystem. The transportation subsystem may be configured to 
schedule deliveries and manage transportation resources related to the fulfillment and 
5 delivery of customer orders. Each of me subsystems of the integrated system 
architecture may effect its various functions via the data network by interacting with 
at least one other of the subsystems. 

Another embodiment of the present invention is directed to an integrated 
system for effecting electronic commerce via a data network. The system comprises a 
10 first business unit for servicing a first plurality of customers associated with in a first 
geographic area; a second business unit for servicing a second plurality of customers 
associated with a second geographic area; and a central management unit for 
managing information content presented by each of the business units to its respective 
customers. Further, each of the business units may comprise an inventory subsystem, 
15 a customer interface subsystem, an order fulfillment subsystem, and a delivery' 
subsystem. According to a specific embodiment, the integrated system may be 
f \ configured to route a particular customer to an appropriate business unit based upon 

V me geographic location associated with that particular customer. 

Additional features and advantages of the various aspects of the present 
20 invention will become apparent from the following description of its preferred 
embodiments, which description should be taken in conjunction with the 
accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWING 
25 FIGURE 1 shows a schematic block diagram of an integrated system 

architecture 100 in accordance with a specific embodiment of the present invention. 

FIGURE 2 shows a schematic block diagram of an integrated system 
architecture 200 in accordance with an alternate embodiment of the present invention. 
FIGURE 2A shows a schematic block diagram illustrating various interactions 
30 which take place between at least a portion of the elements shown in the system 200 
of FIGURE 2. 
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relating to inventory inQow. 

FIGURE 5 shows a state diagram in accordance with a specific embodiment 
of the present invention, illustrating a high-level walkthrough of subsystem 
interactions relating to inventory outflow. 

FIGURES 6. 7A, and 7B show flow diagrams illustrating how various 
systems, subsystems, and components of the present invention interact during normal 
busmess operations in accordance with a specific embodiment of the present 
invention for effecting electronic commerce via a data network. 

FIGURE 8 shows a schematic block diagram illustrating various types of data 
which flow through the Order Management Subsystem (OMS) in accordance with a 
specific embodiment of the present invention. 

FIGURE 9 illustrates various SKU and catalog flows in accordance with a \ 
specific embodiment of the present invention. ) 

FIGURE 10 shows a schematic block diagram of a database reporting and 
analysis environment in accordance with a specific embodiment of the present 

invention. 

FIGURE 11 shows a block diagram illustrating a relationship between 
catalogs, item lists, and store items according to a specific implementation of the 

present invention. 

FIGURE 12 shows- a block diagram illustrating the relationship between 
shipping addresses which fall within mapped area regions, in-area area regions and 
deliverable area regions, fa accordance with a specific embodiment of the present 

invention. 

FIGURE 13 shows a block diagram of a distribution center operation in 
30 accordance with a specific embodiment of the present invention. 

FIGURE 14 shows a flow diagram of an OFS outbound procedure 1400 in 
accordance with a specific embodiment of the present invention. 
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FIGURE IS shows a specific embodiment of an OFS inbound procedure 1500 
in accordance with a specific embodiment of the present invention. 

IET AILED DESCRIPTION ffl? twit p reFERRRH PMpnnmr^ 
According to specific embodiments of the present invention, a technique is 
described for effecting electronic commerce via a data network. More specifically, 
the technique of the present invention utilizes an integrated system architecture for 
effecting electronic commerce via the data network. The data network may be 
comprised of a plurality of separate networks including wide area networks (WANs), 
local area networks (LANs), the Internet, etc. 

The integrated system architecture of the present invention may be used to 
implement a variety of electronic commerce techniques. For example, according to a 
specific embodiment, the integrated system architecture of the present invention may 
be used to implement an on-line store which may be accessed by customers via the 
internet or World Wide Web. Using the technique of the present invention, the on- 
line store may be configured to facilitate customer transactions, including, for 
example, providing customers with catalog information relating to items which are 
available for purchase; enabling customers to schedule a delivery destination, date, 
and time for delivery of an order, receiving and managing customer orders.' 
20 facilitating fulfillment of the customer orders; facilitating delivery of the customer 
orders; etc. The on-line store may include a plurality of systems, subsystems and/or 
components for interfacing with customers via the data network. 

Customer orders received at the on-line store may be forwarded to a physical 
distribution center, where the orders are fulfilled and processed for shipment to the 
customers. Once an order has been processed for shipment to a customer, a delivery 
system may be used for delivering the order to the customer at the specified delivery 
date and time. According to a speciGc embodiment of the present invention, the 
integrated system architecture also includes system elements for managing the 
fulfillment and delivery aspects associated with electronic commerce transactions. 

FIGURE 1 shows a schematic block diagram illustrating various systems, 
subsystems and/or components of the integrated system architecture 100 in 
accordance with a specific embodiment of the present invention. As shown in 
FIGURE I, system 100 includes a plurality of subsystems and other components for 
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WiemlOOofFKnjRElaMyfad^. «»w. For example, 

provides an interface to merchants 133; 

(2) a Webstore Subsystem (WS) 132 which manages the on-line store 

(3) a Transportation Subsystem (XPS) 124 which manages delivery 
device (MFD) data used by delivery couriers; 

(4) an Order Management Subsystem (OMS) ISO which manages pricin fi 

(5) a Corpora Support Subsystem (CSS) 146 which manages financial 
authenticating users and assigning roles; 

n . m. ftui,^, ^ (0FS) 160 which 

(7) . C^er Relationship Man.pmene (CRM) Sub^ta l2 « * 
-tt« cusw «rrfc e (CSRs) H3 „ ^ 

and track customer interaction; 

(8) a Food Production Management Subsystem (MFG) 154 which 
manages information and purchasing requirements relating « 0 recipes, sub-recipes 
ingredients, menus, food safety procedures, equipment usage, etc.; 

" (9) a Data Warehouse Subsystem (DWS) 180 for storing and analyzing 

data reported fiom other subsystems of the integrated system; and 

00) an Electronic Data Interchange (EDI) Subsystem 182 which provides 
an interface to venoors 185. and manages vendor pumluiseomera^dbvoice data. 

30 aUo JuT* ° f * *~* ^ * - — *— - 

(1 1) an Automated Call Distribution (ACQ) Subsystem which manages and 
routes customer calls as they are recei ved at a customer service call center. 
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(12) a Network System Management (NSM) Subsystem which monitors 
and diagnoses all networks and subsystems in the system 100; 

(13) a System and Network Infrastructure (SN1) Subsystem which may 
include hardware and/or software for optimizing network performance, scalability, 

5 and reliability; 

(14) a Corporate Networks and Systems (CNS) Subsystem which 
represents the underlying network foundation upon which corporate systems run; and 

(15) a Content Management Subsystem (CMS) for managing the catalog 
content of a plurality of on-line stores which utilize the integrated system of the 

10 present invention. 

As shown in FIGURE 1, system 100 may include at least a portion of the 
above-described subsystems. Additionally, each subsystem may also comprise at least 
one server and/or other components. Further, each subsystem may be configured to 
utilize a dedicated or shared database server as its persistent and transactional data 
backbone. Users or customers may access data stored on one of the subsystem's 
database servers (e.g. Webstore database), which then executes appropriate business 
logic and/or business objects. 

Each subsystem may be configured or designed to communicate with each 
otherviaapluralityofbterfaces. According to a specific embodiment, the 
plurality of interfaces includes both synchronous and asynchronous interfaces. Many 
of the various system interfaces are configured to be asynchronous, wherein data is 
typically transferred in batch mode via staging (e.g. database) tables or flat files (e.g., 
separated value files). However, at least a portion of the system interfaces are 
configured as synchronous interfaces. Generally, a synchronous interface may be 
used where an immediate response from a server or component is required. 
Synchronous interfaces in the system 100 of FIGURE 1 may exist between WS 130 
and XPS 124, XPS 124 and Route Planner 118, WS 130 and Tax Server 114, and 
MFD server 1 12 and Tax Server 1 14. 

Conceptually, the system 100 of FIGURE 1 may be grouped into two general 
subsystems, namely a Front Office system and a Back Office system. The Front 
Office system is generally responsible for functions related to customer transactions 
such as, for example, customer orders, billing transactions, delivery scheduling, 
customer service, etc. In the embodiment of FIGURE 1, for example, the Front 
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^ (MFD) , „ . „ ^ , ^ 
* Fr« Office ^ l30roly teWe , ^ 

n. w ,c «, „. ^ by ^ cwnponaiis of 

AIM*** one or more of lhc Prom Office systems and/or c^,. „„, ^ 
conpnse . respec*,. ^ ^ js ^ fcy ^ 

components of system 100. 

The Back Office system generally includes all subsystem and/or components 
wh,ch are not part of the Front Office system. Thus, as shown in FIGURE 1 for 
example the Back Office system includes the PUB 140. MFC 154, OMS 150, EDI 
S2, CSS 146, DWS ,80. and OFS ,60 subsystems. However, the invention is no! 
lumted to the particular embodiment shown in FIGURE and it wil, be appreciated 
.bat the specific configumtion of system 100 may be modified by one having ordinary 
20 skill in the art to suit specific applications. 

Subsystem Function^ rry 

This section provides a more detailed description of the various subsystems 
and components which form the integrated system architecture of the present 
invention, as shown, for example, in FIGURE 1 of the drawings. 

25 Publishing Subsystem ( T»tm) 

Referring to FIGURE 1. the Publishing Subsystem 140 maintains and 
manages information data about the retail objects (e.g. SKUs. products, categories 
etc.) which may be available for customer purchase. 

Each different item of inventory is associated with a respective stock keeping 
urut or SKU, regardless of whether the item is available for customer purchase A 
product is a grouping of SKUs. m e product information is the higher level 
mfonnation that is pertinent to all SKUs in the grouping. A category is a hierarchical 
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classification based on how customers would expect products to be logically grouped. 
For example, the category potato chips" may include the products "Brand X" potato 
chips and "Brand Y« potato chips. Further, the Brand X potato chip products may 
include a 16-ounce Brand X potato chips item (associated with a first SKU) and a 20- 
5 ounce Brand X potato chips item (associated with a second SKU). 

The PUB Subsystem 140 may maintain and manage a master catalog of all 
SKU information, including production and supply only SKUs. Additionally, PUB 
Subsystem 140 may also generate and manage different catalogs for different on-line 
stores. Each store catalog may include a selected subset of SKUs from the master 
10 catalog. 

As shown in FIGURE 1, the Publishing Subsystem includes a database 141. 
According to a specific embodiment, the PUB database may be implemented using an 
Oracle database running on a database server. The database is used as a repository of 
all publishing data as well as the repository of code that implements predefined 
15 business rules. 

The data stored within the PUB database 141 may be grouped into a plurality 
of different schemas. including, for example, a data entry schema where all changes 
are initially stored; an integration schema in which changes from at least one user are 
integrated; a master schema which stores a master copy of all retail objects; a catalog 
schema which may be configured as an outbound staging area used by the other 
subsystem interfaces; a publication utility schema which includes stored procedures 
and views which may be implemented by the predefined business rules; a publication 
API schema for allowing both internal and external clients to connect to the PUB 
database; etc. 

25 Merchants and content managers may enter and maintain SKU information 

stored in the PUB database using the PUB Web GUI interface 134 and PUB Bulk 
Loader interface 136. The SKU ^formation may include SKU attribute values such 
as, for example, UPCs. vendors, categories, category hierarchy, images, articles, 
descriptive informaUon, etc. The PUB Web GUI interface 134 allows merchants to 

30 edit SKU information, products, and/or categories. The PUB Bulk Loader 136 
supports the processing of data files from outside the PUB Subsystem into the PUB 
database 141. According to a specific embodiment, the PUB Bulk Loader is 
configured to allow merchants to upload a variety of data file types into the PUB 
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promise (ATP), price, and inventory (e.g„ replenishment and purchasing) informatioD 
for each SKU. OMS may also capture and/or manage sales and shipment data 
relating to each SKU. Periodically. OMS passes new and updated SKU information it 
acquires from the PUB Subsystem to the OFS. The SKU information may be used by 
5 OFS, for example, to maintain physical inventory and fulfill orders. 

Front Office Architectural r*y »r« 

As shown in FIGURE I, the Front Office 130 comprises a plurality of separate 
subsystems such as, for.example, Webstore Subsystem (WS) 132, Transportation 
Subsystem (XPS) 124. and Customer Relationship Management (CRM) Subsystem 
126. Each subsystem may be implemented via a combination of hardware and/or 
software, and further may include a plurality of different functional components, 
modules, and/or plug-in applications. 

At least a portion of the software residing at the Front Office system may 
include a presentation layer, an application layer, a business object layer, a database 
access layer, or any combination thereof. According to a specific embodiment, the 
presentation layer handles the actual presentation of information to users via an 
appropriate medium. The application layer, which may be stateless, handles the 
appropriate application logic for the various subsystems of the Front Office. For 
example, in the Webstore Subsystem 132, it is the application layer (referred to as the 
20 shopping engine) which determines that a customer cannot check out an order unless 
0,(5 cus tomer has selected a delivery window , or provided billing information. The 
business object layer, which may be stateful, provides objects with a fixed set of 
functionality (e.g. methods or procedures) that may be manipulated by the application 
layer. The business object layer may also implement write through caching of data. 
25 According to a specific embodiment, the business objects do not know about each 
other, and the application layer handles the coordination between the various business 
objects. The database access layer provides connectivity and data access APIs to the 
Front Office database 131 (also referred to as the Webstore database). According to a 
specific embodiment, the database access layer performs pooling and caching of 
30 connection objects, where appropriate. 

It is also important for a common database schema to be adopted by each of 
the Front Office systems. According to a specific embodiment, the database 131 is 
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systems. 

Webstore Rnhry*^ fWfl) 

Tte Webstore Subsystem (WS) 132 provides an interface for enabling 
customers to access the on-line store (,g. Webstore). h . ^ 
where the Webstore is implemented as a website on the World Wide Web, customers 
may access the Webstore via the Internet or World Wide Web using any one of a 
Plural^ of conventional browsers. The Webstore user interface may be designed to 

10 according to a specific embodiment, customers may access the Webstore using any" 
chent machine, regardless of the machine's operating system platform. Additionally 
for security purposes, the Webstore interface also supports data encryption for 
exchange of any sensitive or private information between the customers and the 
websrte. According to a specific embodiment, me secure Webstore interface is 

15 rmplemented using a secure http protocol (HTTPS), commonly known to teox o{ 
ordinary skill in the art. 

In accordance with a specific embodiment, the Webstore Subsystem 132 

supporuanumberofcus.omerrelatedfeaturessuchas.forexample.selfregis^ , 
accessmg of customer account information; browsing of product categories ani 
category hierarchy; viewing of product images and product information; keyword 
searches; d elivery sched jriing; accessing of customer order history, customizable 
shopping lists; on-line shopping and ordering; etc 

The Webstore Subsystem (referred to as the Webstore) may be implemented 
usmg at least one server which is connected to the data network. According to a 
25 specific embodiment, the Webstore is implemented using a plurality of web servers 
(e.g. web server farm) which helps to minimize server response time and provide real, 
time failover and redundancy capabilities. Further, according to a specific 
embodiment, in order to keep the web server response time to a minimum the 
Webstore may be configured such that all processing is performed on a single server 
30 wrthin one process. Where a plurality of Webstore servers are used, redundant" 
processing may be performed by at least a portion of the servers so that a single 
Webstore server may handle all Webstore processing tasks associated with a 
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particular on-line customer. It will be appreciated that the Webstore server 
boundaries may be crossed where appropriate, such as. for example, when accessing 
the Front Office database via the data network. 

According to a specific implementation, the presentation layer of the WS 
5 software is implemented in Microsoft Active Server Pages (ASPs) which generates 
HTML data that is sent back to the customer browser. The application software layer 
or shopping engine layer may be implemented as Microsoft Component Object Model 
(COM) objects. The business object layer of the software may provide the following 
business objects: (1) a customer object which implements customer functionality and 
attributes; (2) a catalog object which implements the product category hierarchy, 
SKUs, price, and available-lo-promise (ATP) information; (3) an order object which 
implements the shopping cart, order management, billing, and check-out procedures; 
(4) a session object which implements state over HTTP; and (5 ) a delivery object 
which implements customer delivery schedulin g. Further, the WS is preferably 
5 configured or designed to minimize customer response time and to provide for 
scalability. In an alternate embodiment, the presentation layer could be implemented 
using Java and or Perl, and the application software layer may be implemented using 
NSAPI or Apache modules. 

Additionally, as shown in FIGURE 1, the Front Office system may include a 
5 number of integrated components which provide additional functionality. For 
example, the WS may include a plurality of components which provide additional 
functionality such as, for example, computation of taxes, search capability, credit card 
billing, etc. Thus, as shown in FIGURE 1, for example, the WS 132 includes at least 
one catalog component 122; a tax computation component 114 for computing taxes 
for each order line item that is sold; a search component 120 for processing text 
search requests; and a credit (or debit) card server (CC) component 1 16 for handling 
credit and/or debit card authorizations and funds captures. According to at least one 
embodiment, one or more of these components may be implemented as an 
asynchronous process in order to reduce or rninimize impact on the Webstore server's 
) response time and availability. 
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e ach day, and creates window t emplates for use h y th ft WAim» S'^Tynmi The 
Transportation Subsystem may also include a Delivery Window Estimator cpm nrnimt 
which det ermines which delivery window times are reserved and which delivery 
window ti mes are available for reservation by a customer . Using the data generated 
5 from the Delivery Window Estimator, the Webstore may then display the reserved 
and available delivery windows to the c ustomer. 

According to an alternate embodiment, a delivery business object in the 
Webstore Subsystem estimates and caches information about availability of delivery 
windows on a per-zone, per -subzone, and f»BMa«ftim«»r j^ic when a customer 
requests to view available delivery windows, the delivery business object uses the 
customer delivery address data and the c urrent set of van routes and stops for that 
zone to estim ate and present to the c ustomer avail^s flfiljy prv wigfo^ ft™ " Tntg 
According to a specific embodiment, the available delivery window information is 
presented to the customer u sing a delivery window frrid. 
5 When a customerselects a delivery window , the delivery window business 

object submits the request to the Transportation Subsystem's Route Planner 118. The 
Route Planner then performs a verification check to verify thatthe selected delivery 
window can be promised to the customer. According to a specific embodiment, the 
delivery business object continually adjusts its view of the delivery world in order to 
0 achieve a less than 1% of estimation failures. 

According to a specific embodiment, the Transportation Subsystem may 
include a plurality of Route Planners which are each configured to run concurrently. 
Each Route Planner may be able to allocate or schedule deliveries for a set of zones. 
According to one embodiment, no zone may be serviced by more than one Route 
5 Planner, In the event that a Route Planner fails, (e.g. due to hardware failures), the 
Transportation Subsystem may be designed or configured to cause a different Route 
Planner to take over the delivery scheduling for the set of zones handled by the failed 
Route Planner. In one embodiment the failover operation may be performed 
manually, while in another embodiment the failover operation may be performed 
0 automatically in response to the failure detection. 
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°j Mobile FieM Device (MFIY) ^ mr ~ 

10 Although the MFD server 1,2 may conceptual be grouped with the 

Transports Subsystem, in a specific embodiment, the MFD server component , ,2 
may configured to include at least one back-end server which resides in a particular 
area data center. Thus, different areas may be serviced by different MFD servers 
Moreover, each zone in a particular area may serviced from a station which may be 

15 ejected to the area data center via the data network. Each mobile field device 
(MFD) unit or client 106 may communicate with an area MFD server 1 12 via the data 
network, and download and/or upload various types of information, including, for 
example, customer order history infonnation, l delivery information (e.g. vehicle I 
dehvery routes, stops, etc.), customer returns information, credits, adjustments, etc 1 

Accordmg to a specific implementation, each delivery courier carries an MFD 
dev,ce while making his or her delivery run to the customer sites. Each MFD device 
may be configured to communicate via a wireless communication system with an 
MFD server. For example, the MFD device may include a radio transponder which 
communicates with a radio transceiver for communicating with an MFD server In 

'■S th,s embodiment, it is possible for the MFD device to immediately transmit to the 
MFD server any desired data which the MFD device captures and/or generates while 
in the field. For example, the MFDjiertce^^ 

^formation, a dispatch operator is able to ^Miojpi^ckfteltlms of selected 
0 delivery couriers in the ifcp . Further, acconiir^oT^f^^ 

communication link between the MFD device and the MFD server is broken, the 
MFD device is able to store all processed data which it collects and/or generates in the 
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field and subsequently transmit, via a batched process, the stored data to the MFD 
server when the communication link to the MFD server is re-established. Further, it 
will be appreciated that the MFD device may be configured to fully perform all 
functions and operations at times when the MFD device is unable to communicate 
5 with the MFD server. 

During delivery, the MFD device 106 may be configured to provide the 
delivery operator or courier with delivery route information, including delivery routes 
and stops. Additionally, the MFD device may also be configured to verify delivere d 
items upon deliv ery. Further, using the MFD, the delivery courier is able to 
immediately process a variety of customer service requests at the customer site (e.g. at 
the time of delivery to the customer), such as, for example, order modifications, 
customer returns, billing adjustments, inventory adjustments, credits, etc. According 
to a specific embodiment, the MFD device is able to process these various customer 
service requests using data stored within the device, which has been downloaded into 
15 the MFD unit prior to the delivery. Thus, according to this embodiment, the MFD 
device does not communicate with the MFD server while processing the customer 
service requests at the delivery sight. Alternatively, however, the MFD device may be 
configured to communicate with the area MFD server during processing of the 
customer service request using any one of a number of standard mobile 
20 communication techniques such as, for example, RF data systems, cellular data 
systems, etc. In this latter embodiment, the MFD device may be configured to allow 
processing of customer service requests, even at times when the MFD device is 
temporarily unable to communicate with the MFD server. 

After the MFD has processed all appropriate transactions at the customer 
25 delivery site (including verification of current ordered items received by the 
customer), the MFD may also be configured or designed to provide the customer with 
an adjusted billing receipt (i.e. zero balance receipt), showing a total amount to be 
billed which takes into account any billing adjustments related to any processed 
returns, credits, adjustments, etc. 
30 After completing deliveries on the delivery route, the courier, upon returning 

to the station, may connect the MFD device 106 to the MFD server 112, and upload 
all of the processed field transactions into the area data center, where it is then 
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10 P"st 9 mer Relationship Mm^ rRM l gBhMMtww 

The Customer Relationship Management Subsystem 126 is an interactive 
apphcation which may be used by customer service representatives (CSRs) 143 to 
manage customer service requests and to track customer interaction The 
nationality provided by the CRM subsystem may include, for example, accessing 
customer information; issuing credits for various customer issues (e. g . complaints, 
returns, damaged goods, etc.); handling work fL for processing customer issues- 
etc. The CRM subsystem provides CSRs (sondes referred to as customer service" 
operators - CSOs) with the ability to access, view, and edit customer information in 
accordance with customer requests. 

20 The general architecture of the CRM Subsystem is similar to that of the 

Webstore Subsystem. For example, in a specific embodiment, the CRM subsystem 
may use the same application, business object, and database access layers which is 
used by the Webstore Subsystem. 

In the embodiment shown in FIGURE 1, the CRM subsystem comprises a 
25 Help Desk component 144. In a specific implementation, the Help Desk component 
-s implemented using a Rjm ^software package, manufacture k^ ^o 
of Mountain View, California. The Help Desk component manages any^o^oT 
handhng specific customer requests or issues. For example, the Webstore and 
Transportation Subsystems may generate trouble tickets for various events such as 
30 for example, failed credit card authorizations or customer-reported shorts in delivery! 
The CSRs process these trouble tickets via the Help Desk component 144 of the CRM 
subsystem. Utilizing the Help Desk component, the CSRs are able to initiate and 
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track any customer contact relating to the processed trouble tickets. The CSRs may 
access the Help Desk component 144 via a Help Desk GUI 142. 

According to a specific embodiment, the Help Desk component includes a 
database 145 for managing customer service requests and/or issues. Alternatively, the 
Help Desk component maybe configured to share the Front Office database 131. 

Order Management Subsystem (Q MS) 

The Order Management Subsystem (OMS) 150 manages a variety of aspects 
related to the integrated system architecture of the present invention, including, for 
example, pricing, availability, inventory, vendors, financials, procurement, and data 
10 flows between various subsystems. 

FIGURE 8 shows a block diagram of the different functional elements 
provided by the Order Management Subsystem, as well as the various types of data 
which flow between the Order Management Subsystem and the other subsystems of 
the present invention. As shown in FIGURE 8. the OMS subsystem includes an 
1 5 Enterprise Resource Planning System 810 for processing data received from at least a 
portion of the other subsystems. The data processing system 810 includes an order 
management component 812, a purchasing component 814, a finance component 816, 
a billing component 818. and an inventory component 820. The order management 
component 812 is responsible for managing customer orders. The purchasing 
20 component814isresponsibleforissuingpurcraseorderstoappropriatevena^re. The 
financial component 816 is responsible for managing accounting and finance 
information relating to the entire system operation. The billing component 818 is 
responsible for managing customer billing information, including billed transactions. 
The inventory component 820 is responsible for maintaining inventory records, 
25 determining inventory availability, and replenishment of inventory stock. The various 
data (e.g. 130A, 140A. 154A, 160A, I80A, 190A) which is received at the OMS 
and/or transmitted from the OMS to the other subsystems are described in greater 
detail with respect to FIGURES 6. 7A, and 7B of the drawings. 

As shown in FIGURE 1, the OMS subsystem 150 includes graphical user 
interface 152, and at least one database 151 for storing various data received from at 
least a portion of the other subsystems. According to a specific embodiment, the 
database 151 is configured to include a plurality of schemas, such as, for example, 
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standard packaged application schemas and/or customized schemas. According to a 
specific implementation, the QMS database is configured as a single Oracle database 
running on a Sun Solaris server. 

The Order Management Subsystem is also configured to include appropriate 
5 software and/or hardware for managing financial and distribution applications 
Accordmg to a specific embodiment, the financial and distribution software is 
proved by PeopleSoft Corporation of Pleasanton, California. Additionally the 
financial and distribution application software may include . plurality of components 
such as, for example, a user interface used for inquiry and on-line transaction entry 

10 batch processes used for background processing of data, reports, etc. 

The OMS batch processing may be controlled using a process scheduler The 
process scheduler is able to manage the number of concurrent processes being run and 
the date/time at which certain processes are to run or be executed. The process 
scheduler may also enable central visibility of all processes currently running. Batch 

15 processing and reporting may be accomplished using a variety of different 
technologies commonly known to one having ordinary skill in the art. 

The Order Management Subsystem may be configured to support both 
asynchronous and synchronous interfaces with the other subsystems. In a specific 
embodiment, the OMS is configured to support an asynchronous interface with each 

20 of the other subsystems. This configuration provides a number of advantages 
described in greater detail below. Additionally, each OMS interface is configurable, 
and may be configured to support the running of batch processes as often as is 
desirable. 

According to a specific implementation, all PUB-OMS and WS-OMS 
25 interface programs are configured to operate at the database schema level. New and 
updated data may be posted to a persistent message queue (e.g. staging tables) within 
the data source database. From there, the data may be processed into the destination 


database. 

30 


Further, according to a specific implementation, the interface between PUB 
and OMS may be configured as a single executable program which supports moving 
data (e.g. SKUs, categories, UPCs, etc.) from PUB to OMS. The interface program 
requests the staging of new or updated data by calling a stored procedure in the PUB 
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database, and then inserts/updates the data staged in the QMS database using 
appropriate software which insures data validity. 

Implementation of the various interfaces between OMS and the other 
subsystems may be accomplished using a variety of different techniques commonly 
5 knowntoonehavmgordinaryskillintheart. The following description provides an 
«npto of at least some of the various techniques which may be used for interfacing 
OMS with the other subsystems. However, i, will be appreciated that the specific 
interfaces described be.ow may be implemented using other techniques commonly 
known to those of ordinary skill in the art 
» The interface between the OMS and the Webstore Subsystem may be 

implemented, for example, using a plurality of executable programs. A first portion 
of the executable programs may be responsible for moving data fiom the Webstore to 
the OMS. This data may include, for example, new/updated customer data 
new/updated order data, order cutoff information, order billing information, customer" 
return information, customer credits and fees (e.g. bill adjustment data), etc A 
second portion of the executable programs is responsible for moving data from the 
OMS to the Webstore Subsystem. This data may include, for example, inventory 
data, availability data, pricing data, and information about shipped customer orders. 

The interface between OMS and the Order Fulfillment Subsystem (OFS) 160 
may be implemented, for example, as a flat file interface. Different files may be used 
for each type of transaction within the system. For example, the OFS-OMS interface 
may support the following transactions: (I) new/updated SKU and UPC data from 
OMS to OFS; (2) expected receipts (for vendor purchase orders and special customer 
orders) from OMS to OFS; (3) expected receipt confirmations fiom OFS to OMS- (4) 
planned customer shipment data from OMS to OFS; (5) shipment ^rmnnation data 
from OFS to OMS; (6) and inventory synchronization and adjustment data from OFS 
to OMS. According to a specific embodiment, a third party software package such as, 
for example, Mercator (fiom TSISoft (of Wilton. Connecticut) may be used to map 
data from the OMS database to ASCII files (e.g. flat files) and visa versa. Outbound 
data (from OMS) may be selected directly from tables in the OMS database and 
formatted to the appropriate file format for transfer. Inbound data (to OMS) is 
processed into staging tables within OMS. where it may men be processed into 
transaction tables supported by the OMS batch processes. 
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F_god Production Manage™^ ^f ^m rvn?^ 

The Food Production Management Subsystem (MFC) manages information 
and purchasing requirements relating ,o recipes, sub-rocipes. ingredients, menus, food 
safety procedure,, equipment usage, etc. According to a specific embodiment. SKU 
5 data and costs data may be interlaced from OMS to MFG. MFC then computes the 
cost and nutritional content of a "manufactured" selling SKU (eg. a cooked item), and 
transmits the information back to OMS. MFG may also use food production plan and 
reape mformation to determine ingredient purchasing requirements which will then 
be transmitted to OMS for procurement. 

10 Order Fulfill ment Suhsys ftp fnpg) 

The Order Fulfillment Subsystem 160 manages all functionality of the 
distribution center (DC) 170. In the embodiment of FIGURE I. the OFS includes 
appropriate hardware and/or software for managing the DC facility 170. including, for 
example, a warehouse management system (e.g. software application), at least one 
database 161, at least one interface 162. and an automated material handling (AMH) 
controller component 163. which manages the conveyor, carousel, and scanner 
components. 

In a specific implementation, the Order Fulfillment Subsystem 160 may be 
implemented using a warehouse management system such as. for example, the 
MOVE warehouse management sv^ by ^ of ^ ^ 

California. The warehouse system also provides the interface with the Order 
Management Subsystem. In a specific embodiment, this interface is implemented 
using a business host interface (BHD. The warehouse management subsystem may 
also provide the interface for allowing the OMS subsystem to communicate with the 
25 OFS database 161. 

The warehouse management system communicates instructions (e.g. task lists) 
to the automated material handling controller (AMH) 163. The AMH controller 
processes the instructions and manages the conveyor server 178 and carousel server 
172. The carousel server 172 and the conveyor server 178 may each include a 
respective database 171, 175. The carousel server 172 issues control signals to the 
carousel client 173, which drives the carousel hardware 174 and controls the carousel 
movement. Similarly, the conveyor server 178 processes instructions from the AMH. 
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and issues control signals to the conveyor client 177, which drives and controls the 
conveyors and scanner hardware 176 used for routing inventory and for managing 
traffic. Additionally, the conveyor client 177 and the carousel client may be 
configured with an interface for monitoring the status of the conveyor and carousel 
5 hardware. 

The warehouse management system also communicates with handheld 
computing devices 164 via a wireless interface such as. for example, a radio 
frequency (RF) interface. The handheld computing devices 164 are used by the 
distribution center employees to perform and/or confirm inventory movement 
operations. A graphical user interface 1 62 to may be provided for interfacing with the 
Order Fulfillment Subsystem in order to provide users with the ability to monitor 
distribution center operations and/or manually allocate orders. 

According to one embodiment, the OFS may be defined to include the 
distribution center 170 and all its related elements, including hardware, human 
1 5 resources, inventory stock, etc. In an alternate embodiment, as shown in FIGURE 1 , 
for example, the distribution center 170 may be defined to include the OFS and its 
components (160, 161, 162, 163); carousel and conveyor components 172, 173, 174, 
176, 177, 178; and handheld computing devices 164. 

Data Warehouse Subsystem (DWS1 

20 The Data Warehouse Subsystem 180 is the data repository for information 

from at least a portion of the subsystems which form the integrated system of the 
present invention. The DWS subsystem is configured to analyze the various 
subsystem data and generate reports based on the analyzed data. According to a 
specific embodiment, the Data Warehouse Subsystem maintains a centralized 

25 database. According to an alternate embodiment, the Data Warehouse Subsystem may 
comprise a plurality of databases and other components, including, for example, an 
Operational Data Store (ODS) 181, a Data Warehouse (DW) 189, a data analysis 
component, and a report generating component. 

The Data Warehouse Subsystem periodically polls or captures data from each 

30 of the operational subsystem databases, and stores this information into an 
Operational Data Store (ODS) 181. By collecting data from the various subsystems 
into a single ODS, complex reports and/or queries may be performed on the ODS data 
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more efficiently, and without impacting the performance of the operational 
subsystems. 

Each operational subsystem may include a set of interdependent tables 
referred to as a Data Source. The tables in a Data Source may reside together in one 
5 database, or may reside in different databases, and further may have referential 
constraints among them. A process referred to as "change capture," incrementally 
collects updated and newly inserted rows from each Data Source and stores them into 
staging tables in the ODS. A consistent set of changes for a Data Source may be 
moved from the staging tobies into the ODS at periodic intervals (e.g every 24 
10 hours). 

According to specific embodiments, the ODS includes all or a portion of the 
data source tables from each of the operational subsystems, except for those that are 
explicitly excluded by request of a subsystem administrator. It may also include 
detailed data collected from all Areas and Subsystems. The ODS data may be used, 
for example, for reporting on daily and/or weekly activities and for investigating 
details of operations which have previously occurred. 

The Data Warehouse <DW) 189 comprises tables which are derived from the 
ODS. Preferably the DW tables are designed to facilitate reporting and business 
analysis. According to a specific embodiment, the data in the Data Warehouse is 
aggregated and de-normalized to produce fewer, wider tables that present a "high 
level" description of the business. 

The Data Warehouse Subsystem 180 also provides for operational and 
analytical report functionality. Reports of detailed data from the previous day or 
earlier may query the ODS database. Analytical reports may access both the ODS and 
DW tobies. If reports on the minute-to-minute status of operational subsystems are 
desired, one or more interfaces may be provided to allow the Data Warehouse 
Subsystem to query the operational databases of the desired subsystems. 

According to a specific embodiment, the Data Warehouse Subsystem database 
takes advantages of features such as, for example, a -snapshot log" and ''serializable 
transactions." When a snapshot log is created on a given table, the database software 
creates a side table and a trigger that fires every time the side table is updated, to store 
the changed, added, or deleted record into the table. The DWS can then examine the 
side table and pull only rows that have changed as of a particular time. Serialise 
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□tactions ensure transaction-level consistency in the records. Data may be 
periodically pulled into the staging area (e.g., hourly, daily, etc.). Additionally 
consent transactions may be periodically pulled from ft, staging area into the ODS 
database (e.g., hourly, daily, etc.). 

5 As shown in FIGURE 10. the ODS database 181 and the Data Warehouse 

database 189 may be used to provide a plurality of reports including, for example, ad 
hoc reports 1002. status reports 1004, daily reports 1006. yearly reports 1008. 
summary reports 1010. and other types of analytical reports 1012. 


IS 


20 


10 Integrated system ARrrn-rrcnmE oppp ati^ 

In order to gain a better understanding of the integrated nature of the system 
architecture of the present invention, it will be helpful to review the interactions 
between the various subsystems during normal business operations. 

FIGURES 4 and 5 provide high-level data now diagrams of the various 
subsystem interactions during normal business operations. More specifically. 
FIGURE 4 provides a high-level walkthrough of subsystem interactions relating to 
inventory inflow (e.g. inventory replenishment). FIGURE 5 presents a high-level 
walkthrough of subsystem interactions relating to inventory outflow (e.g. customer 
order fulfillment and delivery). 

Referring to FIGURE 4, at (I) new or modified item (SKU) information may 
be entered by a merchant into the PUB Subsystem 140 via either the PUB Web GUI 
(134, FIGURE 1) or Bulk Loader interface (136, FIGURE 1). The SKU information 
may include descriptive information about the item such as, for example, UPC codes, 
images, nutritional information, attributes, product name, etc. 

At (2a) the OMS periodically polls the PUB for new or updated SKU data. 
The new/updated SKU data is stored within the OMS database 151 (FIGURE 1). At 
(2b) the SKU data is also automatically exported to the database and catalog 
components of the Front Office system 130. According to the embodiment of 
FIGURE 4, however, new items which are imported into the master Webstore catalog 
are not made available to customers until a purchase order has been issued for the new 
item. At (2c) the OMS periodically sends to the OFS the new/updated SKU data. 
The new/updated SKU data is stored in the OFS database 161 (Figure !). 
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At (3) it is assumed that a buyer has approved a purchase order (PO) which 

ft. PO to been approved, at (4a) the PO is automatically sen, „ *. appropriate 

5 for the purchase order itemfs) is automatically issued torn OMS 150 to OFS 160 
The expected receipt Worms OFS that specific item quantities (related to the 
purchase order) are expected to arrive at the distribution center on or near , particular 

date. 

Additionally, after the purchase order for the new item has been approved at 
(4c) the OMS ISO automatically informs the Front Office system 130 of 'the 
availability and price of the new item. In at least one embodiment, avai.ability 
mcludes specific data about how many units of the new item will be available on 
specfic dates. This availability data is referred to as available- to .p ro mise (ATP) data 
Further, in at least one embodiment, price data may be computed or set and 
15 approved (c.g.. by buyers) in the OMS. According to a specific implementation, 
pnemg may be computed based upon a cost plus pricing method. Accordingly the 
pnee of a particular item (SKU) which is viewed by a customer in a first geographic 
area may be different than the pricing information displayed to a customer in a second 
geograpluc area, depending upon the relative cost involved in storing the particular 
20 item in each geographic area. When new prices are approved. OMS publishes them 
to the Webstore Subsystem, which then updates the pricing information displayed to 
the customer. 

The pricing for a particular item may be based upon the descriptive 
•nformauon which the merchant provides for that item or SKU. Accordingly, pricing 

25 may therefore be determined automatically using a predetermined set of rules which 
may be different for each geographic area. For example, when a purchase order for an 
item occurs, the attributes associated with that item (SKU) are assigned a cost factor 
or a number specific to the geographic area in which the item is to be delivered 
Pricing for the ordered item may then be automatically determined based upon this 

30 cost factor. 

Once the Webstore receives the ATP and price data of a new item, at (5) the 
new item information is automatically made available for customer viewing and 
purchasing. The item infomiation displayed to the customer may be obtained from 
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the catalog data previously imported into the Webstore catalog from the PUB 
Subsystem. 

At (6) it is assumed that a vendor shipment relating to the new purchase order 
item(s) is received at the distribution center. At (7) the received shipment is 
5 processed, which includes inventorying and storing each item of the received 
shipment. Once the received shipment has been processed, at (8) an expected receipt 
confirmation is issued from OFS 160 to OMS 150. Additionally, OFS provides any 
inventory adjustments (e.g. shorts) relating to the original purchase order and the 
received shipment. When the OMS receives the expected receipt confirmation data, 
10 at (9) the OMS processes the data and updates its inventory records and ATP 
information. Once the OMS inventory records have been updated, at (10a) the OMS 
performs any necessary financial transactions relating to the purchase order, based 
upon the expected receipt confirmation data. Additionally, at (10b) revised ATP and 
inventory data relating to the received item(s) are sent from the OMS 150 to the Front 
Office system 130. At (1 1), the Front Office system (e.g. Webstore) updates its ATP 
and inventory records for the appropriate item(s) based upon the revised data received 
from the OMS. 

At (12), the vendor issues an invoice for the purchase order shipment via the 
EDI subsystem 182. It will be appreciated, however, that this latter event may occur 

20 at any time after the purchase order has been received by the vendor. 

The example of FIGURE 4 illustrates several unique and advantageous 
features which may be attributable to the integrated nature of the system architecture 
of the present invention. For example, the asynchronous architecture of the Back 
Office system enables a merchant to enter descriptive product information into the 

25 PUB Subsystem 140 at any time. PUB Subsystem components such as, for 
example, the Bulk Loader 136, automatically classify, categorize, sort and catalog the 
received merchant data. Once processed, the received merchant data is stored in the 
PUB Subsystem. Thus, it will be appreciated that the entire publication and 
cataloging process of the integrated system may be automatically driven by the 

30 merchants. This process provides cost efficiency by eliminating labor costs which 
would otherwise be required for PUB system operators to manually maintain and 
update the publication/catalog database. 
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maintaining all aspects of inventory inflow. 

Ref ^S* FIGURE 5,.^^ 
relatmg to inventory outflow (e.g. customer ordering, fulfillment, ^ deIivny) „ 
shown. At (1) an order is placed by a customer via the Webstore of the Front Office 
system 130. According to a specific embodiment, the customer order is placed after 
the customer performs a "checkout" procedure whereby items from the customer's 
electromc shopping cart are processed for sale. After the customer completes the 
checkout procedure, at (2a) the Webstore performs tax computation and credit card 
authorization for the total value of the order. According to at least one embodiment 
the customer is not bi.led for the order at this time. Rather, using the customer's' 
creda, card or debit card information, a* authorization is obtained which verifies the 
available credit limit and validity of the customer's credit or debit account 
Accordmg to a specific embodiment, tax computation and credit card authorization 
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may be performed by the tax and credit card systems 414 (HOUR* 5) which, in the 
embodiment of FIGURE 1, are components of the Webstore Subsystem 132. Further, 
according to a specific embodiment, each scheduled order will have an associated 
credit (or debit) card authorization. 
5 After the customer order has been placed, but before a predetermined cutoff 

time has passed, the customer may cancel or modify any part of the order, including 
modifying the delivery time window associated with the order. Customer service 
representatives (CSRs) are also permitted to make changes to scheduled orders until 
cutoff time. Additionally, during this time, at (2b) the OMS periodically polls the 
Webstore for new or updated scheduled orders so that the OMS may process any 
necessary demand planning. According to a specific implementation, the cutoff time 
for a particular customer order is determined based on the delivery window of the 
scheduled order. 

In a specific embodiment, order modifications mav be implemented by 
making a new Webstore order, which is an action that may create new scheduled 
orders or change existing scheduled orders. A customer or CSR may make changes 
such as, for example, deletion of ordered items, modifying the quantity of one or more 
ordered items, modifying delivery times or delivery destinations, or canceling entire 
shipments. If changes require any credit card re-authorization, the Front Office 
20 software will handle it. 

At cutoff time, the Transportation Subsystem of the Front Office adds 
finalized route i nformation to the customer order . After the cutoff time, at (3) the 
OMS polls the Webstore to obtain the final "information relating to the scheduled 
orders). Additionally, the Webstore updates its ATP data relating to items associated 

25 with the scheduled orders). According to an alternate embodiment, the Webstore 
may update its ATP data each time it modifies the contents of a customer's electronic 
shopping cart Once the Webstore provides the updated ATP data to the OMS, the 
OMS updates its ATP data so that it is in synchronization with the Webstore ATP 
data. According to a specific embodiment, the only time that the OMS and WS ATP 

30 data are out of synchronization is when new deliveries are received at the distribution 
center, and the new ATP data has not yet been propagated to the Webstore. The OMS 
calculates its ATP data based upon customer orders at the Webstore and upon 
shipments received at the distribution center. 
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According to a specific embodiment, before the cutoff time has occurred, the 
OMS may place the customer order on hold to prevent it from being passed to the 
OFS for fulfillment After cutoff, when the order is ••final" or ••frozen," the OMS will 
remove the hold on the order so that the order will be passed to the OFS 160 for 
5 fulfillment, as shown at (4). An order may be considered final or frozen when all of 
its mformation <e.g. order information and delivery information) is final. The order 
data which is transferred to the OFS subsystem 160 may include both SKU data and 
transportation/delivery data (e.g. delivery vehicle routes, stops, etc.). 

At (5) orders received at the OFS subsystem are fulfilled and processed for 
shmment to the customers. The ordered items are transported in contains or totes. 
Each tote has a unique physical license plate ID which includes bar codes that may be 
read by a scanner. Each tote is associated with a respective customer order. Each 
customer order may comprise one or more totes. 

After the order has been fulfilled and processed for shipment, at (6) the OFS 
transmits post fulfillment status data rehiring to the customer order to the OMS The 
post fulfillment status data may include, for example, the number of totes and the 
physical license plate ID of each tote associated with the customer order, the ID of 
each shipping dolly used to transport the totes to and from the delivery trucks, and/or 
the vehicle ID associated with the shipped order. At (7) the OMS relays the shipment 
status information to the Webstore of the Front Office system 130. The shipment 
status data may include adjustments for ordered items which were not fulfilled. Upon 
receiving the shipment status data, the Webstore updates the order status of the 
shipped order, which may be accessed by the customer and CSRs. 

Once the shipment status information is received at the Front Office system 
25 130, at (8) the Front Office system downloads delivery list data, customer order 
history data, and delivery route data to the mobile field device (MFD) system 412. 
According to a specific embodiment, the Transportation Subsystem of the Front 
Office transmits the delivery list, customer order history, and delivery route data to an 
MFD server, which then downloads the data into a mobile field device (i.e MFD or 
30 MFD client). 

After the proper data has been downloaded into the MFD, the delivery courier 
may be dispatched to deliver the order to the customer. At (9) the order is delivered 
to the customer by the delivery courier. At this time, the delivery courier may use the 
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mobile field device to process tote returns, item returns, order modifications, order 
adjustments, credits, tax calculations, etc. According to a specific embodiment, the 
mobile field device (MFD) is configured to process the above-described customer 
service transactions without communication to the MFD server. After the various 
5 customer service requests have been processed by the MFD. the courier may present 
the customer with a modified billing receipt which includes an adjusted total amount 
that takes into account any processed returns, order modifications, adjustments, 
credits, and/or new tax calculations. 

Additionally, at the time delivery is made to the customer, the delivery courier 
may scan each delivered item using the MFD in order to generate a record of items 
actually received by the customer. This information is stored in the MFD along with 
a delivery time stamp. 

When the delivery courier returns to the area station, the processed data stored 
in the MFD is uploaded to the MFD server. According to a specific embodiment, the 
MFD data may also be remotely uploaded into the MFD server via a wireless 
communication system, while the delivery courier is in the field. At (10) the delivery 
transaction data is transferred from the MFD system 412 to the Front Office system 
130. According to a specific embodiment, the MFD server transfers the delivery 
transaction data to the Transportation Subsystem, which then updates the order status 
information in the Front Office database. At (11) the Front Office system performs 
final tax calculations based upon the updated order status information, and initiates a 
funds capture using the customer's billing information. It is at this point that the 
customer is actually billed for the order. Moreover, the billed amount will take into 
account any returns, order modification, adjustments, and/or credits which were 
25 processed by the MFD at the time of delivery. 

At (12) the Webstore transmits the final invoice data and returns data to the 
OMS. The OMS processes the final invoice data and returns data, and updates the 
customer invoice and billing records accordingly. Additionally, at (13) the OMS 
notifies the OFS of any returns (by way of advance shipment nolices-ASNs) so that 
30 the OFS may properly process the returned items once received. At (14) the returned 
items are received and processed by the OFS. After the returned items have been 
processed and restocked in the distribution center, at (15) the OFS transmits returns 
confirmation data to the OMS. The OMS then updates its inventory and ATP data 
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based upon the returns confirmation data received from OFS. Additionally at (16) 
the OMS forwards the updated ATP data to the Front Office system 130, hereupon 
the Webstore updates its ATP information. 

As mentioned previously, the integrated nature of the system architecture of 
5 the present invention provides a number of unique and novel advantages which are 
not realized by conventional systems such as those described in the background of 
this application. For example, one advantage of the technique of the present 
invention relates to the ability of a customer to modify an order after it has been 
placed. As described in FIGURE 5, orders may be modified by the customer at any 
lime before the designated cutotTtime for that order. Additionally, the customer may 
also modify the order at the time of delivery. Moreover, the system of the present 
invention provides the ability for customer returns, credits, and/or adjustments to also 
be processed at the time of delivery. These latter features are made possible, in part, 
due to the integration of the delivery courier and mobile field device with the othcJ 
15 subsystems of the present invention. 

Another advantage of the technique of the present invention relates to the 
timing of customer billing. As stated previously, conventional on-line stores typically 
bill a customer for an order at the time of shipment. However, according to the 
technique of the present invention, the customer is billed after delivery of the order to 
the customer. Moreover, the integrated nature of the system architecture of the 
present invention enables the total billing amount to be adjusted to reflect any returns, 
order modifications, credits, and/or adjustments which were processed at the time of 
delivery or at the time of a scheduled pickup. Further, by providing a modified or 
"zero balance" receipt to the customer at the time of delivery, the customer receives 
immediate confirmation of all currently pending charges for which the customer will 
be billed. This provides the customer assurances that no additional or hidden charges 
will appear on the customer's credit or debit account. 

Further, the integrated architecture of the system of the present invention may 
also provide for real-time failover capabilities. More specifically, the asynchronous 
design of the system architecture allows the system to continue operating despite one 
or more subsystems going down. For example, a temporary subsystem failure at the 
OMS will not affect the customer shopping and order functions performed by the 
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Front Office system 130. Additionally, backed up data may be queued and batched 
for processing when the down system comes back on line. 

■fa Capacity and ATP Data Calcnlatf onc 

Another advantage of the integrated system architecture of the present 
5 invention relates to available-to-promise (ATP) iiiforraation about catalog items 
presented to the customer, and th e reservation and allocation of resource capacity 
within the various subsystems. According to at least one embodiment of the present 
invention, the inflow of orders is managed at the time of ordering based upon 
available capacity of selected subsystem s. The ATP information associated with a 

1 0 particular item may be used to regulate the order inflow for that item. 

According to a specific embodiment, the Webstore Subsystem keeps track of 
the number of available items, and allows customers to select only items that are 
g uaranteed to be available in a given time slot The display may be based upon 
expected (e.g.. scheduled) arrival of SKUs into the distribution center. If a shipment 

15 does not arrive or is delayed, this information is propagated to the WS, whereupon the 
WS automatically updates the availability information relating to the items of the 
delayed shipment. The WS may keep track of the time slots in which an item is 
available, using, for example, "available", "in sitqck", "available until", and "available 
on" labels in the store display. j 

20 According to an alternate embodiment, ATP values (e.g., quantities of specific 

items which are available to promise) are computed in OMS and published to the 
Webstore. The ATP data may be computed, for example, based on a SKU inventory I 
management method, an ATP method, physical inventory quantity, and/or quantities 
scheduled to be received from vendors. 

25 Further, according to a specific implementation, each item or SKU has an 

a ssociated capacity profile relati ng to an amount of ca pacity to be reserved in various 
subsystems to g uarantee fulfillment and delivery of the i tem on the specified delivery 
date and time. The capacity profile of a particular item may include a plurality of 
Individual capacity attributes such as. for example, an inventory type attribute, a pick 

30 type attribute, a time attribute, a space attribute, etc. The inventory type attribute 
relates to whether an item exists as an "on the shelf' item (referred to as "dwelled" 
inventory, such as, for example, a bag of Brand X potato chips) or whether the item 
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type attnbutc relates to the storage conditions associated with the item such as for 
example, room temperature storage (ambient), chilled, or frozen, The ^ 
relates to estimated amounts of human resource time it will take to fulfill and deliver 
' theorder. Ttall»^^ hdrt .^ rfl-b<|i ^ 

^•Pfc-.^^.^*.^ TT.espaceattn^uterelatesto 
the physical space requirements associated with the item. 

According to a specific embodiment of the present invention, the Webstore 
"2 mamtains JLr^uce^paci^ cache of cim^tly ^ablc and reserve d 
c apactv .resource s corresponding to selected subsystems. When77ustomer selects! 
particular item for purchase, the Webstore retrieves the capacity profile for the 

selected item, and uses mis data to dggmjne whether there i. ^ 

cagacitvjiubiL selected sub-syst^ ^ ensure that the selected item m » v i» fi „ fi ,u, 
and delivered to the customer by Unspecified delivery date, location, and time U 
•here are insufficient capacity resources in any of the selected subsystems, the 
Webstore will not show the item as available for sale or delivery for the specified 
delivery time window. 

If. however, the Webstor^etommes that there jue sufficient c-d tv 
resources in each of the selected subsystems to ensure that the selected item mayTe 
fulfilled and delivered to the customer by the specified delivery time window, the 
Webstore Subsystem ^BUtBlLt U^d item to be added ,n customtfs 
electronic st ,q RP » ne pa rt. Additionally, as the Webstore Subsystem adds the item to 
the customer's electronic shopping cart, it also r eserves a specific amount of 
capacty in each of the selected subsystem, ^dating ,h. H^ gT^,, 
resource capacity data cache. According to this specific embodimenlmTa^unt of 
capacity reserved by th e Webstore in each of the selected subsystems is related to the 
capacity profile attributes of the rtgggditj. In this way, the Webstore Subsystem 
may continually keep track of available resource capacity in each of the selected 
subsystems in order to compute ATP data relating to Webstore catalog items, and 
further, may use this data to replate the inflow of customer orders at the time of 
ordering. 

The following example provides an illustration of this concept. In this 
example, it is assumed that a customer wishes to add a container of ice cream to the 
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customed clonic shopping cart When the customer selects the container ice 
cream to be added to his or her shopping cart, the Webstore Subsystem may first 
determine, for example, the selected item availability (e.g. available quantity for the 
specified delivery date), the storage temperature of the item, whether there are 
sufficent human resources to fulfill theitgnorjerby the specified delivery rime, and 
whether there are sufficient transportation resources available to deliver the item by 
the specified delivery time, including whether there is su fficient space in the freezer 
°f "e delivery vehicle to accommodate the ord^d item on the specified 
dehvery date. Assuming that each of these resources is available, the Webstore adds 
10 •heselecteditemtoU.ecustomCsshoppingcart. Additionally, upon adding the item 
to the shopping cart, the Webstore Subsysten^ghs ufficient amount of c apacity 
m selected subsystems to ensure that the orderedit^T^e successful fulfill* 
and delivered to the customer by the specified delivery date and time. 

If a customer subsequently modifies an order (before the cutoff time) or 
deletes an item from the customer's shopping cart (before checkout), the Webstore 

Subsystem autom i ri i al ^ 

so that this capacity may be reserved by other customers. Capacity may also be freed 
if the customer abandons his or her shoppjng session and/or faib jo.proceed to 
customer check-out 

According to one embodiment of the present invention, the Webstore 
Subsystem is responsible for computing current ATP data and for maintaining 
reserved and available resource capacity records corresponding to selected 
subsystems. However, according to a different embodiment, the OMS may perform 
these functions. 

25 Data Flows 

Figures 6, 7A and 7B, illustrate specie embodiments of data flow diagrams 
of various subsystem and component interactions of the present invention during 
normal business operations. 

It will be appreciated that the various data flows illustrated in Figures 6, 7A, 
30 and 7B are not necessarily presented according to a specific chronological order'. As' 
explained in greater detail below, data flow from one subsystem to a second 
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subsystem may be triggered in response to an occurrence of an event. Other types of 
data flows in Figures 6. 7A and 7B may be initiated at predetermined time intervals 

Referring to FIGURE 6. at (A) the OMS 1 50 polls the PUB Subsystem 140 for 
new or updated item data at periodic intervals, which may range from minutes to 
> day, According to a specific embodiment, the OMS may poll the PUB Subsystem for 
new/updated item data about every thirty minutes. The item data may include for 
example, new or updated SKU data, UPC data, vendor data, etc. 

At (B) the OMS processes the received item data, and transmits to the OFS 
SKU information (e.g. UPC and product master da*) a, periodic intervals such as for 
» example, every two hours. According to a specific embodiment, the product master 
data includes a list of all assigned SKUs m the integrated system, as well as UPC and 
descriptive data associated with each SKU. 

At (C) a PO is created or generated at the OMS. In response, an expected 
rece.pt for the PO is transmitted from the OMS to the OFS. At (D) the PO 
merchandise is received, inventoried, and put away. Once the received inventory has 
been processed by the OFS, the OFS send an expected receipt confirmation to the 
OMS. The OMS uses the expected receipt confirmation data to update its inventory 
and ATP data. At (E) ATP and price data is sent from OMS to the Front Office 130 
a. periodic intervals. For example, ATP data may be sent every hour, and price data 
may be sent every 24 hours. Further, according to a specific embodiment, all data 
sent from the OMS to the Front Office is stored in the Front Office database 131 
(figure 1 ), which may be referred to as the Webstore database. 

At (F) new or updated customer information is received from the customer at 
the Webstore Subsystem. In response, this data is forwarded from ttxe Webstore to 
the OMS. At (G) an order checkout or order update action is completed at the Front 
Office. According to a specific embodiment, when a customer places an order on the 
on-line store, the Webstore Subsystem creates a sales order and a scheduled shipment 
for the customer order. The sales order may include one or more order lines 
representing the items, quantities, and prices of ordered items that have been 
promised to be delivered to a customer's location at a scheduled delivery window. 
Further, according to at least one embodiment, the scheduled delivery window is 
captured in the scheduled shipment Additionally, for each scheduled shipment, the \ 
Transportation Subsystem schedules a vehicle stop on a particular delivery route ' 
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According to a specific embodiment, the OMS periodically polls the Webstore 
database for new orders, order updates, and order cancellations. The received data is 
then processed in the OMS. 

At (H) cutoff time occurs. According to a specific embodiment, the cutoff 
5 time for a particular customer order is based upon the delivery window time 
associated wilh that customer order. There may be several cutoff times during any 
given time period (e.g. several different cutoff times each day), wherein each different 
cutoff time corresponds to a specific portion of customer orders associated with 
specific delivery window times. For example, customer orders to be delivered 

10 between 9:00 am and 1 :00 pm on a particular day may have a cutoff time of 12:01 am 
that same day, while customer orders to be delivered between 1:01 pm and 6:00 pm 
on a particular day may have a cutoff time of 4:01 am that same day. 

At order cutoff, the Front Office performs cutoff processing on orders that are 
ready for cutoff, which is based upon a time value needed for the order to be fulfilled 

15 and shipped out of the distribution center in order to be delivered on time to the 
customer's delivery address. In one embodiment, the Transportation Subsystem cutoff 
processing optimizes all delivery vehicle routes that are ready for cutoff Webstore 
cutoff processing may perform substitutions on order lines for SKUs that are 
oversold. According to a specific embodiment, orders that have completed WS and 

20 XPS cutoff processing are detected by the OMS. In response, the OMS may poll the 
Webstore database for additional information relating to the cutoff orders (including 

< fill-tc-order or FTO data). The OMS then performs its cutoff processing on the cutoff 
order and FTO data, and generates (I) order and FTO download files which may then 
be transmitted to the OFS subsystem for fulfillment and shipment. 

25 The OFS processes the order download files transmitted from OMS, and 

stores the cutoff order information in the OFS database (161, FIGURE 1). The OFS 
includes an order allocation component which allocates inventory to the cutoff orders, 
canonizes the order lines (e.g., assigns one or more totes to each order line), and 
creates picking tasks. The automated material handling component of the OFS 

30 subsystem reads the picking tasks, and transmits data to the carousel and conveyor 
servers (172, 178, FIGURE 1) to operate the carousels and conveyors, and to instruct 
the distribution center personnel on which items to pick and the respective quantity. 
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After FTO processing has been completed for a particular order, at (J) FTO 
confirmation data is sent from OFS to OMS. Moreover, after a specified number of 
orders has been fulfilled and processed for shipment to the customers or stations), at 
(K) OFS performs a shipment confirmation (ship confinn), which creates a ship 
5 confinn upload file to be sent to the OMS. As stated previously, the ship confinn 
data may include, for example, inventory data of items (SKUs) which have been 
picked and shipped in each order shipment, tote ID data, tnmsportadon/delivery data, 
etc. 

Once the OMS has received and processed the ship confirm data and updated 
its inventory data records, at (L) the ship confirm data is forwarded to the Front Office 
system for processing. According to a specific embodiment, when all orders for a 
particular delivery vehicle route are ship confirmed, the Transportation Subsystem 
generates the MFD data for the delivery route, which includes information about 
shipments and stops for the route. In addition, the Transportation Subsystem may 
also generate van route summaries, delivery lists, driving directions for the route, etc. 
At (M) the Front Office system transmits customer order history data and 
transportation/delivery data to the MFD subsystem 512. According to a specific 
embodiment, the MFD subsystem includes an MFD server and at least one MFD 
client (e.g. MFD handheld device). As described previously, the MFD server loads 
the customer order history data and route/delivery data for a particular delivery route 
into the MFD associated with the delivery courier assigned to that route. Thereafter, 
the delivery courier may be dispatched to deliver the order to the customer. 

At the time of delivery, the courier may use the MFD client to process 
customer returns, order modifications, credits, and/or adjustments. The MFD then re- 
computes the customer billing data to take into account any returns, credits, or other 
adjustments. At (N) the delivery courier returns to the station, and uploads the 
revised customer billing data and returns data from the MFD client into the MFD 
server. The MFD server then forwards the billing data and returns data to the Front 
Office 130. At (O) the customer is billed using the revised billing data received from 
the MFD server. After a customer has been billed for a particular order, the order is 
closed. According to a specific embodiment, the OMS periodically polls the 
Webstore Subsystem for closed orders and posts the received data to the OMS finance 
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component. Additionally, at (Q) the returns data is received at the Front Office 
system, where it is processed and forwarded to the OMS. 

It will be appreciated that, in at least one embodiment, returns, fees, and/or 
credits for customer accounts may be generated and captured in the Webstore 
Subsystem both during and after delivery. Examples of fees may include a delivery 
fee, a returned tote deposit, a cancellation fee, etc. Examples of credits include a late 
delivery credit, a tote deposit credit, etc. According to a specific embodiment OMS 
periodically polk the Webstore database for RMAs, fees and credits in order to 
accurately update its inventory and finance data. 

Additionally, according to a specific embodiment, the Webstore may 
automatically update its ATP data and inventory data based upon the received returns 
data in order to allow the returned items to be immediately available for customer 
purchase. However, according to an alternate embodiment, the Webstore will not 
make it available for purchase until it receives a confirmation that the returned items 
1 5 have been received at the distribution center. 

At (R) the OMS receives and processes the returns data and issues an expected 
returns receipt (RMA) to the OFS. Return merchandise authorizations (RMAs) may 
be created, for example, in response to item returns, item shortages, damage to items, 
etc. At(S)merehjmeditem(s)arei^ivedatftefctributioncenter(DC). After the 
20 returned items have been inspected and processed at the DC (e.g. checked in and put 
away), an RMA confirmation is sent from the OFS to the OMS. The RMA 
confirmation may include, for example, SKU data relating to actual items of returned 
inventory which were restocked in the distribution center. 

Periodically, the OFS may detect a change in inventory, such as, for example, 
25 due to expired goods, damaged goods, etc. At (T) the OFS periodically sends 
inventory adjustment data to the OMS for processing. This inventory adjustment data 
will eventually propagate to the Webstore Subsystem for processing. 

At (U) a bill adjustment action is initiated by a CRM at the request of a 
customer. The bill adjust data is then sent from the CRM subsystem to the OMS for 
30 processing. 

At (V) a retum-to-vendor (RTV) action is initiated at the OMS. In response, 
the planned RTV shipment data is sent from OMS to OFS for processing. After the 
specified merchandise has been shipped to the vendor, at (W), the OFS sends an RTV 
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specific embodiment, the zone window creator is initiated every 24 hours to create a 
new delivery window for one or more days in the future. 

At (6) a customer accesses the Webstore 132 via the Internet. The customer 
may transmit customer data (e.g„ registration data) to the Webstore, which is received 
at (8). Alternatively, customer data may be retrieved by the Webstore from the cheat 
computer which may be stored, for example, in a cookie file. According to a specific 
embodiment, customers may register themselves and maintain their own account 
information at the Webstore Subsystem. When the customer data is received at 
the Webstore Subsystem, the WS may retrieve personalized customer preferences 
from the database in order to present customized and preferred data to the customer. 
Periodically, OMS polls the Webstore database for new and/or updated customer 
information. 

At (10) the customer accesses the delivery window scheduling po rtion of the 
Webstore, which is managed by the Tra nsportation Subsystem . The customer does 
not necessarily have to reserve a delivery window time slot before shopping on the 
Webstore. However, according to one embodiment, the cu stomer must schedule a 
deli very window time slot before being allowed to proceed to checkou t 

Further, according to a specific embodiment, when a customer first registers at 
the Webstore, the customer is asked to provide a delivery address. The address is 
then converted to a latitude/longitude pair by a Geocoder component of XPS i 
Subsystem, which may consults per-area street map for performing this conversion. 
The latitude/longitude pair is then determined to be either in-area or out-of-area by a 
ZoneResolver component of XPS. If the address is in-area, the Zone Resolvcr also 
determines the specific zone and subzone associated with the delivery address. This 
25 zone and subzone information may then be stored as part of the customer's record, 
30(1 ms »y be used tP det ermine the specific delivery i» m e to be used for delivering 
orders to the customer. The initial address is the default address used for all 
subsequent orders placed by the customer. However, the customer may change the 
delivery address on a per-delivery basis for anv delivery , and may also change the 
30 default address for all deliveries at any time. 

When a delivery window request is received (12) at the Transportation 
Subsystem (XPS), it accesses the Webstore database to retrieve delivery scheduling 
data and the Delivery Window Estimator component o f the Transportation Subsystem 
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8enemeS 5" list of available and u,availab le ^ which 

.sAsplayedtothecustomcratd^. At (16) the customer select, ,n 

window time slot The delivery window selection data is sent to the XPS The»S 

processes (18) the delivery window selection data, and retrieves the customer address 

data from the Webstore database. The djUyer*wta^^ 

data ,s then forwarded to the Route Planner component (618) of thTr^o^tio", 

Subsystem. The Route Planner processes the delivery w,^ ^ ^ ^ 

ether confirms or denies the delivery window request According to a specific 

embodtment, the Route Planner utilizes transportation scheduling and optimization 

software (SOS) to determine whether a particular delivery window request is to be 

confirmed or denied. 

The Route Planner, may consider a plurality of factors when validating a 
particular delivery window request For example, there .must be sufficient 
resource capacity , in the Transportation Subsystem before a particular deliver 
window request may be confirmed. Additionally, the customer address or shipping 
address must be mapped with a pre-determined deliverable area. 

For example, according to the specific embodiment of the present invention, 
order deliveries may only be scheduled for addresses which fall within pre-determined 
'^HbJslior^. FIGURE 12 illustrates the relationship between customer 
addresses which fall within "mapped" area regions 1202, "in-area" area regions 1204 
and "deliverable" area regions 1206 in accordance with the specific embodiment of 
the present invention. Generally, a customer address is the representation of a 
physical place to which goods may be delivered. A mapped address is an address 
which has a corresponding record in the Transportation Subsystem database. An in- 
area address is an address which is within the geographic area serviced by one of the 
system's distribution centers. A deliverable address corresponds to an address where 
shipments are allowed to be delivered by the delivery couriers associated with the 
Transportation Subsystem. An additional address type corresponds to a common 
carrier deliverable address, which is an address to which orders may be shipped by 
common carrier such as, for example, UPS, or the U.S. Postal Service. An address 
may be both deliverable and common carrier deliverable. 

According to a specific embodiment a deliverable address is one which is also 
in-area. However, there are in-area addresses which are not part of the deliverable 
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address subset. For example, a particular geographic region may be classified as in- 
area, but not deliverable. 

Assuming that the customer address corresponds to a deliverable address, and 
that the delivery window request is available, a delivery window confine,! ls 
> issued (20) from the Route Planner to the Transportation Subsystem, where it is then 
forwarded (22) to the customer. Additionally, upon c ojdinning the delivery window I 
request, the Route Planner forwards to the Webstore databa se transportation c r c i«v / 
data which is to be reserved for the c onfirmed deliv^y ^..^ 1 

At some point when the customer is interacting with the Webstore, the 
customer may chose to initiate a search for specific items or products. At (24), the 
customer submits search data to the Webstore Subsystem. Upon receiving the search 
data, the Webstore Subsystem accesses (25) the Webstore database, in order to 
retrieve the search results. Once retrieved, at (26) the search results are then 
displayed to the customer. 

At (28) the customer submits a request for viewing information related to 
specific items and/or products. When the request is received (29) at the Webstore 
Subsystem, the WS access the Webstore database in order to retrieve information 
about the selected items/products, including price and availability. The retrieved 

information is then displayed to the customer at (30). 

At (32) the customer selects a particular item to be added to the customer's 
electronic shopping cart, or for immediate purchase. When the item selection data is 
received (34) at the Webstore Subsystem, the Webstore processes the selected item 
request. During this processing, the Webstore Subsystem accesses the subsystem 
resource capacity information stored in the Webstore database (or in a working 
memory cache) to verify that there is sufficient capacity in selected subsystems to 
ensure that the selected item can be fulfilled and delivered to the customer at the 
specified delivery window. Once the Webstore Subsystem verifies that the selected 
item may be added to the customer's shopping cart, the WS updates the capacity 
information in the Webstore database (or capacity data cache) by reserving a 
suffi ciem amount of capacity in each of the selected subsystems to ensure that the 
selected item may be fulfilled and delivered to the customer at the specified delivery 
time window. After the Webstore has added the selected item to the customer's 
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electronic shopping cart, the Webstore reports and/or displays (36) this ^formation to 

the customer. 

After the customer has finished shopping at the Webstore, he/she may initiate 
a checkout procedure in order to purchase the selected items in a customer's electronic 
i shopping cart. When the customer checkout request is received at the Webstore 
Subsystem, the WS forwards (40) the order information to the tax server 114 
(FIGURE 1) to compute the appropriate taxes for the order. The tax server 114 
computes the appropriate taxes based upon the order information and transmits (42) 
the computed tax data back to the Webstore. Additionally, at checkout, the WS also 
retrieves capacity information relating to the order (e.g„ volume information relating 
to the number of totes which will be needed for fulfilling the order). Once the tax data 
and capacity information have been received, the WS processes (43) the sales order. 
The sales order data is then stored on the Webstore database. 

At (44) the funds capturing component (CC. 1 16) of the Webstore Subsystem 
automatically detects the new sales order data at the Webstore database 631, and 
initiates a credit (or debit) card authorization for the total amount of the sales order. 
When the authorization is received, the authorization information is stored at the 
Webstore database. However, if there is a problem obtaining authorization for the 
customer's credit (or debit) card, the CC component 1 16 may issue a trouble ticket to 
the Help Desk 144 for special handling. Assuming that a credit or debit card 
authorization is obtained for a particular sales order, the WS forwards the sales order 
data from the database 63 1 to the OMS for processing (46). 

After the customer has placed a particular order at the Webstore, the customer 
may modify or cancel the order at any time until a pre-determined cutoff time 
associated with that order has passed. When a customer desires to modify a particular 
order, for example, he/she submits (48) the order modification information to the 
Webstore. Upon receiving the order modification data, the WS processes (50) the 
data, and updates the sales order data stored on the Webstore database. The 
processing of an order modification information may include, for example, 
recalculating tax, capacity, and other information related to the order. The updated 
sales order data may also sent to the OMS for processing 

As shown at (52) a customer may also achieve modification or cancellation of 
an order via the CRM subsystem 126. For example, the customer may telephone a 
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customer service representative (CSR) and ask the CSR to modify or cancel a 
particular order. The CSR may implement the order modification via the CRM 
subsystem 126. The CRM processes (54) the order modification data, and updates the 
sales order data stored on the Webstore database. 

At (56) the order cutofftime occurs. At this point, the customer can no 
longer modify the order (until it is delivered). A plurality of events which occur after 
the cutofftime has passed or elapsed are described in FIGURE 7B of the drawings. 

The data flow diagram of FIGURE 7B may be thought of as continuing fiom 
where the data flow of FIGURE 7A left off. However, for purposes of clarification 
and in order to avoid confusion, several subsystems and/or components from 
FIGURE 7A have been omitted from FIGURE 7B in order to provide a more 
simplified illustration. 

As shown in FIGURE 7B. at (56) the order cutoff time occurs. After the 
cutofftime has occurred for a particular order, the OMS forwards (58) the sales order 
data relating to the cutoff order to OFS. When OFS receives the sales order, it 
processes (i.e.. fulfills) the order, and transfers the processed order to an area delivery 
station for delivery to the customer. After the order has been processed and shipped 
to the delivery station, at (60) the OFS sends shipment confirmation date to OMS. 
The OMS then processes (62) the shipment confirmation data received from OFS at 
20 least a portion of the shipment confirmation data to the Webstore Database. 

Upon detecting and retrieving the shipment confiimation data from the 
Webstore database, the Transportation Subsystem generates MFD data, which 
include, for example, customer order history information, delivery vehicle routing 
information, shipment data, etc At (64), the MFD data is then sent to the MFD 
25 subsystem, whereupon it is then downloaded into appropriate MFDs. According to a 
specific embodiment, each MFD may be assigned to a different delivery courier. The 
MFD server uses the delivery courier association information to determine the 
particular MFD data set to be downloaded into each MFD. According to a specific 
implementation, the delivery courier is responsible for downloading and uploading 
30 data between the MFD and the MFD server. 

After the appropriate MFD data has been downloaded into a particular MFD, a 
download confirmation message may be sent (65) from the MFD subsystem 512 to 
the Transportation Subsystem. Upon receiving the MFD data download confirmation, 
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The delivery courier may process (74) the customer service requests) using 
the MFD IP-dedthatmeMPDhasbeencon^o.p^^.^J 
r^s). After processing the customer service request, the MFD re-computes the 
customer's balance and generates (76) a modified receipt showing the adjusted 
balance. The modified receipt may also include a list of all billed items, item returns 
adjustments, credits, etc. The receipt is then Rented (78) by the delivery courier to' 
the customer. 

Additionally, according to a specific embodiment, the delivery courier may 
unpack each tote at the customer site, and use the MFD to scan each item delivered to 
the customer, m this way, any order adjustments (e.g., due to shorn or damaged 
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items) may be immediately processed, and the customer only billed for actual items 
received. 

At (79) the delivery courier returns to the delivery or cross-dock station and 
uploads the data from his/her MFD into the MFD server. The MFD server then 
i forwards the customer returns data and modified billing data to the Webstore database 
via the Transportation Subsystem. Additionally, the modified customer billing data is 
also detected and retrieved by the funds capture component 1 1 6. Using the modified 
billing data, the funds capture component initiates (80) a funds capture from the 
customer's financial account. If the funds capture is unsuccessful, a trouble ticket 
may be issued to the Help Desk 144 for special handling. Assuming, however, that 
the funds capture is successful, the payment confirmation information is stored on the 
Webstore database. According to a specific embodiment, billing adjustments to 
customer accounts may also be implemented by the CRM Subsystem. In the example 
shown in 7B, the customer requests (82) a bill adjustment to be initiated via the CRM. 
Upon receiving the bill adjustment request, the CRM generates (84) bill adjustment 
data and passes the bill adjustment data to the Webstore to beprocessed and stored on 
the Webstore database. 

At (85) the OMS periodically polls the Webstore database to retrieve customer 
returns data, customer billing data, and customer billing adjustment data. According 
20 to a specific embodiment, the OMS may poll the Webstore database every 2 hours to 
retrieve the completed ordering data. 

As shown at (86), the CRM may also be used by a customer to schedule a 
delivery pickup, without having to place a new order. For example, the customer may 
schedule a delivery pickup for a specific time with a CSR. The CSR forwards (88) 
25 the pickup data to the CRM, which then forwards the pickup data to the 
Transportation Subsystem for scheduling. 

Catalop Or ganization 

FIGURE 11 shows a block diagram illustrating the relationships between 
catalogs, store brand catalogs, store catalogs, item lists, and store items, in accordance 
30 with a specific embodiment of the present invention. Each of the catalogs illustrated 
in FIGURE 1 1 may be generated by PUB Subsystem 140. Alternatively, at least a 
portion of the catalogs may be generated by Webstore Subsystem 132. As illustrated 
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in FIGURE 1 1 , a master catalog 1 102 may include all SKU ^formation stored within 
the PUB Subsystem. A store brand catalog 1 104 is a subset of the master catalog. A 
store catalog 1 106 is a subset of the associated store brand catalog. 

According to a specific embodiment, each store or store type represented by 
5 the system of the present invention may have a particular "look and feel," such as, for 
example, a convenience store, a general department store, a grocery store, a specialty 
store, etc. A store brand may be thought of as a brand unit which represents a 
common identity for group of stores. For example, "Webvan Market" is the store 
brand for the stores "Webvan Market-Bay Area" and "Webvan Market-Atlanta." 

A store brand may include a plurality of stores. Each store may be associated 
with one or more distribution centers. However, according to at least one 
embodiment, a distribution center may only be associated with at most one store per 
store brand. Thus, for example, no stores belonging to the same store brand will 
overlap a given service area. Moreover, a customer may automatically be routed to an 
appropriate store based upon the delivery address of the customer. 

In a manner similar to the catalog hierarchy, items handled by a regional or 
area distribution center may be derived from a subset of the SKUs identified in the 
master catalog. For example, as shown in FIGURE 11, an area DC item list 1110 is a 
subset of its regional DC item list 1 108. Store items may be constructed based on a 
particular store catalog and a particular DC item list A store item represents what is 
displayed to a customer at a particular on-line store or webstore. 

One important aspect of the present invention relates to scalability and data 
integration. According to a specific embodiment, all SKU information which is used 
by each subsystem of the present invention is based upon the SKU data derived fiom 
the master catalog of the Publication Subsystem. Thus, for example, all merchandise 
residing in each regional DC (worldwide) will have the same SKU association, which 
is based upon the master catalog defined by a centralized PUB Subsystem. 

Distribution (Wq- 

FIGURE 13 shows a block diagram of a distribution center (DC) operation in 
accordance with a specific embodiment of the present invention. In the embodiment 
of FIGURE 13, DC 1300 is configured to function as an area DC for customer order 
fulfillment. However, according to an alternate embodiment, DC 1300 may be 
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configured to fiinction as a regional DC which services multiple area DCs. 
Additionally DC 1300 may also manage common carrier shipping of selected orders. 

As shown in FIGURE 13, the DC 1300 organizes inventory merchandise into 
different "picking" categories, depending upon the recommended storage temperature 
5 of the item. Thus, for example, an item which is typically stored at ambient or room 
temperature will be stocked in the ambient inventory section (1302) of the DC. 
Refrigerated items are stored in the chilled inventory section (1304) of the DC, and 
frozen items are stored in the frozen inventory section (1306) of the DC. The DC 
may also include at least one food production section 1308 which prepares pre- 
packaged meals and other food products. Additionally, the DC may also include one 
or more fill-to-order (FTO) sections (e.g. 13I0A) for processing customer specific 
orders such as, for example, special food orders, produce orders, meat orders, etc. 
According to a specific embodiment, each inventory section of the DC (1302, 1304, 
1306) may include a respective FTO section (e.g. 1310A. 1310B, I310C). Further, 
DC 1300 may also include a common carrier packaging and shipping section 1312, 
which may be used, for example, for shipping items to customers (via common 
carrier) who do not reside in a deliverable area serviced by the delivery couriers of the 
present invention. 

As described previously with respect to FIGURE 1, the distribution center 
includes a system of conveyors, carousels, scanners, and hand-held computing units 
for automating both the order fulfillment (outbound) and inventory restocking 
(inbound) processes, which are managed by the Order Fulfillment Subsystem 1 60. 

FIGURE 14 shows a flow diagram of an OFS Outbound Procedure 1400 in 
accordance with a specific embodiment of the present invention. The OFS Outbound 
25 Procedure generally describes the events which may occur during fulfillment of a 
customer order. At 1402, the OFS receives a customer order from the OMS. The 
OFS then allocates (1404) the order, wherein the physical warehouse location of each 
item of the order is determined. Using the order allocation data, the OFS then 
determines (1406") the number 0 f totes needed to adequately fulfill the order, and the 
optimal tote path for each tote. At 1408 the tote(s) are inducted into the DC 
carousel/conveyer system. Each tote automatically traverses (1410) a pre-detennined, 
designated tote path. The tote path may be dynamically and automatically altered if 
problems are detected in any portion of the DC operations. While the tote is 
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traversing its designated path, i« makes stops at designated .ocations within the DC 
whe^te.ns^gtoftecusto.ero.deraresto.d. A human operator or "picker" 
Places specked order items into » tote, and verifies the order item ftfaL by 
seeing each item p,aced into the to,, as weU as the tote's license plate ID. with I 

^«-P*l«.Mp* Afterd.epickerhascoaiir.nedp.acement 
cf the speeded items into the designated tote, the tote is then reintroduced to the 

^ , AftW K n i,emS * PiUtiCU,ar 10,6 Picked Md -^ed, the tote is 

routed to a shipping spur where it is consolidated (1412) onto an appropriate dolly 

wh,ch may include other totes intended for a specific delivery route. Th. dolly and 
totes are men loaded (14,4) onto a truck or omer vehicle for shipment to a cross dock 
(or area dehvery) station. At the cross dock station, ,he totes wi.l be loaded into 
*£y vehicles for dehvery to the customers. According to an alternate 
embodiment, at lest a portion of the customer totes may be shipped directly from the 
area DC to the customer, thereby eliminating the cross dock station transfer. Once the 
tot«s) corresponding to a particular customer order have been shipped to the cross 
dock station (or directly to the customer), the QMS is notified (1416) of the shipment 
confirmation. According to a specific embodiment, the shipment confirmation data 
sen, to the QMS from the OFS may include, for example, the order ID, an order line 
number (SKU) for each item shipped (as well as the quantity), the tote IDs associated 
with the order, the dolly ID, the delivery vehicle ID, etc. 

Like the outbound procedure, items may 'be received and restocked in the 
dmnbution center using the automated materia, haling and transport system 
illustrated, for example, in block 1 70 of Figure 1 . 

FIGURE 15 shows a flow diagram of an OFS inbound procedure 1500 in 
accordance with the specific embodiment of the present invention. Tue inventory 
restocking process initially begins at the OMS where a purchase order is generated for 
spectfic inventory items. At 1502, an expected receipt relating to the purchase order 
» received at the OFS from the OMS. The expected receipt data may include for 
example, the vendor name, an expected receipt ID number, estimated arrival time of 
the shipment, and the SKUs and quantities of the items ordered. Once the expected 
sh.pmen, is received (1504) at the distribution center, the received merchandise is 
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checked (1506) into appropriate trays. A tray represents a container which may be 
used to transport received items of merchandise for restocking, like the tote, each 
tray includes a unique, scannable license plate ED. When merchandise is checked into 
a tray, both the merchandise and the tray may be scanned using an RF gun. The trays 

5 are then automatically routed (1508) to their appropriate locations using the 
automated conveyer system. Once a tray arrives at its designated location, the items 
from that particular tray are stored (1510) and confirmed by the picker (via an RF 
gun, for example). According to a specific embodiment, for each completed tray of 
items restocked, an expected receipt confirmation is generated (1512) by the OFS and 

10 sent to the OMS. The expected receipt confirmation data may include, for example, 
the expected receipt ID, the SKU(s) of the items restocked and their respective 
quantities. 


Other Embodiments 

15 FIGURE 2 shows a block diagram of an alternate embodiment of the 

integrated system 200 of the present invention. The embodiment of FIGURE 2 is 
particularly useful for allowing different webstores to present different information 
about the same product to different customers which reside in different geographic 
areas. Thus, for example, customers A (202A) may reside in San Francisco, while 

20 customers B (202B) may reside in Atlanta. As used in this section, the term 
"webstore" represents an on-line store which is implemented via a respective 
Webstore Subsystem. 

Using the technique of the present invention as shown in FIGURE 2, a first 
webstore (204A) may be customized specifically for customers A (e.g. residing in San 

25 Francisco), and a second webstore (204B) may be customized specifically for 
customers B (e.g. residing in Atlanta). The different webstore customizations may 
include, for example, different languages, different descriptions of the same item (e.g. 
"soda" vs. "pop-), different catalog items displayed to the customers, different pricing, 
etc. Each webstore 204A and 204B may be serviced by one or more respective 

30 servers 206A and 206B. Moreover, as shown in FIGURE 2, each webstore 
implementation includes a respective Front Office system and Back Office system, as 
well as centralized Publication, Data Warehouse, and CSS Subsystems. For example, 
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^ weostore 204A is managed primarily by aa Ana A business unit 230A, 
wrn* UKl.de. . FroM o«e, s„em 2,0, . Back omce a»T 

BOB. winch tncbdes a respecnVe fma 0ffloe 

DWS MF 0 . CSS) of each respecU,. „, ^ ^ ^ 

A primly oVBerenee between embodiTOM of 

(Figure 4 and a hewers (HQ) business unit 279. As shown in FIGURE 2 for 
» een^lized nunaged system 2 ,o may comprise . „ „ • 

on each of the webstores 204A. 204B. Addi.ion.Uy th. oemraj 

for mauging corresponding aaelhte suborns u, each of the are. busiLs 

torn both OMS-A222A and OMS-B222B, etc. 

The headquKtera business unit 279 manages a» business unit operas™, ^ 
nclufcs a pturahty of HQ subsystems (eg, DWS-HQ 272. CSS-HQ 2,4. OMS-HQ 

for e*amp,e associate scheduling for the customer service eali center. OMS-HQ 27« 
pnmarily maMges ftance factions associated win HQ business operations 

One important feature relattog „ „, „ mouRE 
.nformatton and content relaung to etth ,f ft, spcciBc webstores 204A, 204B is 
managed by the central management system 280. rune, Ouu, any of the area business 
230B. This feahue is described in greater detai, w„h refe^ . 

FIGURE 2A shows . Mock diagram jllushating the inter^ons between at 
leas, a poruon of me subsystems shown in FIGURE 2. In the embodiment of 
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FIGURE 2A, a centralized PUB Subsystem 256 manages and controls all SKU and 
catalog content for each of the area business units 230A, 230B (and also for each of 
the area specific webstores). The functionality of PUB Subsystem 256 is similar to 
that of PUB Subsystem 140 of FIGURE 1. 
5 Thus, for example, in a manner similar to that described in FIGURE 9, the 

PUB Subsystem 256 (Figure 2A) publishes appropriate SKU information to each of 
the satellite OMS subsystems 224A, 224B. This data eventually gets propagated to 
respective OFS subsystems 224A, 224B. Additionally, the PUB Subsystem 256 
publishes its data to each satellite Prep Subsystem 217A, 217B, wherein the data is 

1 0 eventually passed to the respective WS subsystems 212A, 2 1 2B. 

The PUB Subsystem 256 also publishes its catalog data to the Content 
Management Subsystem (CMS) 252. The function of the CMS 252 is to create and 
maintain the content pages for each of the webstores 204A and 204B. The catalog 
content infomiation for each webstore is then exported to the Store Catalog block 

15 250, which includes a database or other memory structure for storing the different 
webstore catalogs. The webstore servers 206A, 206B access the appropriate store 
catalog information stored in the catalog database 250, and display the retrieved 
information to their respective customers 202 A and 202B. 

Catalog block 250 may include a plurality of store catalogs, including, a 

20 master catalog, store brand catalogs, and store catalogs. The master catalog includes 
all SKU information from the Publishing Subsystem 256. A store brand catalog 
includes a group of SKUs that are available to the stores associated with a given store 
brand. According to a specific embodiment, each store brand has one store brand 
catalog. A store catalog may include a list of all stores' SKUs for a given store. 

25 Additionally, it will be appreciated that a SKU may be available to a specific store 
catalog, but may not have been selected to be displayed to the customer. 

Another feature of the embodiment of FIGURE 2A relates to the centralized 
customer support center. For example, as shown in FIGURE 2A, customer service 
representatives may be accessed by customers 202A and 202B via a centralized Help 

30 Desk subsystem 254. The Help Desk subsystem 254 is configured to allow to be 
accessible to customers from different geographic areas. Thus, according to a specific 
embodiment, there is one centralized customer service operation serving all customers 
of a given area such as, for example, the United States. 
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FIGURE 2A. The Publiatta, Subs*™ 356 publishes it, cautog data to the 
Comer,, Management Subsystem 352. From there the d«. I, proceed, am, „ 

20 ^-350,wh i chm v b.^ bywebstoIesmmJ06 .^^^J 
« me informs «,,„ wn am ^ „ ^ ^ 

corresponding to each webstorc. 

their own on-line storefronts via an Internet API 382. According to one 
unplementation, an affiliate is a third party which sells merchandise to customers 302 

' ™tT ° f " St0rCS ** * U ***** * «— 300 of 

FIGURE 3. The affiliate may control the content of the affiliate store catalog 
however, shopping, orderi „ g , mi]meRt> ^ ^ vety m ^ ^ 

units (e.g.320A,320B) 

30 ^ tomw ^PP"gandoidermgi 8 handIedbyareabusin^ 320At 

320B,etc.). A customer may be routed to the closest area business unit based upon j 
the customers delivcy address or other information relating to the customers 
pineal locatioa Thus, for example, a customer from Atlanta will be routed to the 
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Atlanta business unit, whereas a customer from San Francisco will be routed to the 
San Francisco business unit for handling shopping, ordering, fulfillment and delivery 
details. Alternatively customers from different areas may be routed to a single Front 
Office system configured to handle customer ordering, shopping, and other electronic 
commerce transactions. 

Although several preferred embodiments of this invention have been 
descnbed in detail herein with reference to the accompanying drawings, it is to be 
understood that the invention is not limited to these precise embodiments, and that 
various changes and modifications may be effected therein by one skilled in the art 
without departing from the scope of spirit of the invention as defined in the appended 
claims. 
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1. An integrated system for effecting electronic conunerce via a data 
network, the system comprising: 

» invotey mOToiyi ^ ^ ^ 

of a plurality of items of merchandise; 

k " CUSt ° mer i" communication with the inventory 

subsystem, said customer interface subsystem being configure, or designed to store 
av ^nven^ 

10 or deagned to present selected item information relating to said inventory 
merchandise to at least one customer, said customer interface subsystem being further 
configured or designed to facilitate customer shopping transactions, and to store 

customer order information; 

an order fulfillment subsystem in communication with said inventory 
15 subsystem, said order fulfillment subsystem being configured or designed to receive 
sard customer order information, said order information including at least one 
customer order for at least one item, said order fulfillment subsystem further being 
configured or designed to facilitate fulfillment of said customer order, wherein 
fulfillment of a customer order includes obtaining at least a portion of items relating 
20 to the order, and preparing the obtained items for shipment to the customer, and 

a delivery subsystem in communication with said customer interface 
subsystem and said inventory subsystem, said delivery subsystem being configured or 
des.gned to receive items relating to at least one fulfilled customer order, said delivery 
subsystem further being configured or designed to facilitate delivery of said received 
25 items to said at least one customer. 


30 


2- The system as recited in any of claims 1 further comprising a data 
warehouse subsystem for receiving and analyzing data generated from the other 

plurality of subsystems, 

3. The system as recited in any of claims 1-2 wherein said inventory 
subsystem is further configured or designed to manage customer orders received from 
the customer interface subsystem, and to manage customer billing data relating to the 
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4. The system as recited in any of claims M wherein said inventory 
subsystem comprises: 

an order management subsystem configured or designed «o manage customer 
orders received from the customer interface subsystem; 

a financial accounting subsystem for managing financial information relating 
to purchasing and sales transactions; and 

an inventory replenishment subsystem configured or designed to manage 
inventory stock quantities, and to generate vendor purchase orders for acquiring 
additional inventory stock. 

5. The system as recited in any of claims M further comprising a 
publishing subsystem in communication with said inventory subsystem and said 
customer interface subsystem for managing catalog data associated with each item of 

merchandise. 

6. The system as recited in any of claims 5 wherein said publishing 
subsystem is further configured or designed to manage information content presented 

20 by the customer interface subsystem to the at least one customer. 

7. The system as recited in any of claims 5-6 wherein said catalog data 
includes descriptive information about each item. 

25 8. The system as recited in any of claims 7 wherein said descriptive 

information includes a SKU identifier and a UPC identifier for each item. 

9. The system as recited in any of claims 5-8 wherein said publishing 
subsystem includes an interface for allowing merchants to enter catalog data into said 

30 publishing system. 

10. The system as recited in any of claims 5-9 wheiein said publishing 
subsystem is further configured or designed to use at least a portion of said catalog 
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subsystem. ^ 

U. THe system as recited in any of claims 5-10 wherein said customer 
mterface subsystem includes a representation of a. least one store catalog including 
mformationrelating to at least a portion of said plurality ofitems of merchandise, said 
system being further configured or designed to cause said at least one store catalog to 
be automatically updated at predetermined intervals using said catalog data from said 
publishing subsystem. 


10 


12. The system as recited in any of claims 5-1 1 wherein said inventory 
subsystem includes a master item database of each item of merchandise, said system 
bemg further configured or designed to cause said master hem database to be 
automatically updated at predetermined interval using said catalog data from said 

1 5 publishing subsystem. 

13. The system as recited in claim 10 wherein said customer interface 
subsystem includes a representation of at least one customer catalog representing 
selected items of merchandise to be displayed to a customer, wherein said system is 

20 further configured or designed to automatically modify customer catalog data based 

upon available inventory data. 

14. The system as recited in any of claims 5-13 wherein said inventory 
subsystem is further configured or designed to generate a new purchase order (PO) for 

25 at least one item included in said inventory records, automatically determine new 
pricing herniation for said at least one item based upon data from said purchase 
order, and automatically issuing, to the order fulfillment subsystem, an expected 
receipt relating to the purchase order. 

30 15. The system as recited in claim 14 wherein said inventory subsystem is 

further configured or designed to automatically inform at least one vendor of the 
generated purchase order. 
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16. The system as recited in claim 13 wherein: 

said inventory subsystem is farther configured or designed to generate a new 
purchase order (PO) for at least one item included in said inventory records, 
automatically determine new pricing information for said at least one item based upon 
i data from said purchase order, and automatically inform at least one vendor of the 
generated purchase order; and wherein 

said system is further configured or designed to automatically update available 
inventory data stored in the customer interface subsystem using data from said 
generated purchase order. 

17. The system as recited in claim 16 wherein said customer interface 
subsystem is further configured or designed to automatically modify the customer 
catalog to include any new items relating to the generated purchase order. 

18. The system as recited in any of claims 1-17 wherein said customer 
interface subsystem farther comprises a storefront inventory database for storing item 
inventory data, said item inventory data including item availability data and price 
data. 


19. The system as recited in claim 18 wherein said storefront inventory 
database includes available to promise (ATP) inventory data corresponding to items 
of inventory which are available to promise for delivery to customers on a specified 
delivery date. 


20. The system as recited in claim 19 wherein said customer interface 
subsystem is farther configured or designed to compute said ATP inventory data 
based on data stored in said storefront inventory database. 


21. The system as recited in claim 20 wherein said customer interface 
30 subsystem is farther configured or designed to automatically re-compute at least a 
portion of said ATP data in response an item being selected for purchase by a 
customer. 
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mterface subsystem is further configured or designed to modify said item inventory 
data « response to an item being selected for purchase by a customer. 

"> 2*. The system as recited in any of claims 18-21. wherein said customer 

interface subsystem is further configured or designed to manage customer orders and 
order modifications using item inventory data. 

25. The system as recited in any of claims 18-21, wherein said customer 
15 mterface subsystem is mrther configured or designed to allow customers to modify 

receded orders until a predetermined cutofftime has passed. 

26. The system as recited in claim 25 wherein said system is further 

configured or designed to automatically export customer order data from said 

20 customer interface subsystem to said inventory subsystem after a pre-defined cutoff 
time has passed. 


25 


30 


27. The system as recited in claim 26 wherein said system is further 
configured or designed to automatically export said order data from said inventory 
subsystem to said order fulfillment subsystem after said pre-defined cutoff time has 

passed. 

28. The system as recited in any of claims 18-27 wherein said system is 
fiirther configured or designed to automatically update inventory records in said 
inventory subsystem in response to an order shipment confirmation being received 
from the order fulfillment subsystem. 

29. The system as recited in any of claims 1-28 wherein each item has 
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associated with it a respective set of capacity attributes corresponding to an amount of 
capacity to be reserved in each subsystem in response to an item being selected for 
purchase by a customer. 

5 30. TTie system as recited in claim 29 wherein each set of capacity 

attributes includes: 

at least one inventory capacity attribute; 
at least one delivery capacity attribute; and 
at least one order fulfillment capacity attribute. 

31. The system as recited in any of claims 29-30 wherein the customer 
interface subsystem further comprises a capacity database for managing capacity data 
associated with the plurality of subsystems, said capacity data including available 
capacity data for each subsystem and reserved capacity data for each subsystem, the 
customer interface subsystem being further configured or designed to manage inflow 
of customer orders at time of ordering using said capacity data. 

32. The system as recited in claim 31 wherein said capacity data for a 
selected item includes: 

20 inventory type information relating to the selected item; 

transportation information relating to the selected item; and 
fulfillment information relating to the selected item. 

33. The system as recited in any of claims 3 1 -32 wherein said system is 
25 further configured or designed to automatically update said capacity data at 

respective, pre-determined intervals using data from each of said subsystems. 

34. The system as recited in any of claims 31-33 wherein said customer 
interface subsystem is further configured or designed to reserve a respective amount 

30 of capacity in said capacity database for selected subsystems in response to an item 
being selected for purchase by a customer, the amount of capacity reserved for a 
selected subsystem being related to the set of capacity attributes associated with the 
selected item. 
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35. The system as recited fa claim 34 wherein said customer interface 
subsystem ,s further configured or desigaed to automatically modify the reserved 
am, associated with a, least one order* i tem fa ^ „ g 
5 modifying a desired quantity of the at least one item. 

sub, J'' • " h C,aim 35 WhCreia S8id CUSt0me ' 

sub ystem ,s further configured or design* to free the reserved capacity associated 

wth an ordered item when the customer cancels an associated order for the at least 

10 one ordered item. 

37. The system as recited in any of claims 31-36 wherein the customer 
interface subsystem is further configured or designed to use said capacity data to 
indicate to the at least one customer which inventory items are available for purchase 

15 ^^^mldM^Uav^M^toto*^*****. ' 

38. The system as recited in any of claims 1-37 wherein said delivery 

subsystem comprises: 

a transportation subsystem including a plurality of delivery vehicles and a 
20 delivery route management subsystem; 

at least one delivery courier; and 

at least one mobile field device (MFD), said MFD including memory 
configured or designed to store delivery route information and order history data 
corresponding to selected customers. 

25 

39. The system as recited in claim 38 wherein the delivery subsystem 
further includes an customer delivery mapping subsystem, said customer delivery 
mappmg subsystem being configured or designed to determine whether delivery 
service is available to a selected customer based upon the customer's delivery address. 

40. The system as recited in claim 39 wherein the determination of 
delivery service availability to the selected customer is not based upon a zip code 
associated with the delivery address of the customer. 
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4i. The system as recited in any of claims 3840, said system being further 
configured or designed to allow a customer to modify an order upon delivery of the 
order to the customer. 


is 


42. The system as recited in any of claims 38-41, wherein the MFD 
further configured or designed to remotely process modifications of a customer order 
during delivery of the order to the customer, 

10 43. The system as recited in claim 42 wherein the MFD is further 

configured or designed to allow the delivery courier to process at least one customer 
service request while the delivery courier is at the customer's delivery address. 

44. The system as recited in claim 43 wherein the customer service request 
1 5 includes a request to return a previously ordered item. 

45. The system as recited in any of claims 43-44 wherein the customer 
service request includes a request to modify an order currently being delivered to the 
customer. 

20 

46. The system as recited in any of claims 38-44 wherein the system is 
further configured or designed to enable the at least one delivery courier to receive at 
least one returned item from a customer, and is further configured or designed to 
enable the at least one delivery person to immediately process the at least one returned 

25 item using the MFD. 

47. The system as recited in any of claims 38-44 wherein the system is 
further configured or designed to enable the at least one delivery courier to use the 
MFD to process customer service requests during delivery of an order to the 

30 customer, and to present a modified receipt to the customer, the modified receipt 
having a total amount to be billed which automatically accounts for any billing 
.adjustments related to the processed customer service requests. 
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delivered to said at least one customer. 

51. The system as recited in any of claims 1-50 wherein said ordering 
15 factions include scheduling a delivery time window for said selected items to be 
delivered to said at least one customer. 


52. 


The system as recited in any of claims 1-51 wherein said delivery 
sub ^™<Wisesade^^ 

20 window data, and wherein said customer interface subsystem is configured or 
designed to utilize said delivery window data for scheduling a de.ivery time window 
for sa,d selected items to be delivered to said at least one customer. 

W « .rn UC mm " reCUed h ° f ClaimS M2 Wbcrein -to 

25 fulfillment subsystem is further configured or designed to transmit shipment 

confirmation data to the inventory subsystem relating to orders for inventory items 
which have been successfully fulfilled and shipped to customers. 

in . ,«„ m SySlen, 88 rCCited iB my ° f daimS M3 where » ^d order 

■JO fulfillment subsystem comprises: 

a storage center for storing at least a portion of said inventory items- 
at leas, one collection container for receiving at least a portion of items 
associated with a respective customer order, and 
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an automated container transportation system for transporting said at least one 
container to various locations within said storage center for order fulfillment. 

55. An integrated system for effecting electronic commerce via a data 
5 network, the system comprising: 

a first business unit for servicing a first plurality of customers associated with 
a first geographic area, the first business unit comprising: 

a first inventory subsystem comprising memory, said first inventory subsystem 
including an inventory database configured or designed to maintain inventory records 
10 of a plurality of items of merchandise; 

a first customer interface subsystem in communication with the first inventory 
subsystem, said first customer interface subsystem being configured or designed to 
present selected item information relating to said inventory items to at least one 
customer, said first customer interface subsystem being further configured or 
15 designed to facilitate customer shopping transactions, and to store customer order 
information; 

a first order fulfillment subsystem in communication with said first inventory 
subsystem, said first order fulfillment subsystem being configured or designed to 
receive customer order information, said order information including at least one 
20 customer order for at least one item, said first order fulfillment subsystem further 
being configured or designed to facilitate fulfillment of said customer order, and 

a first delivery subsystem in communication with said first customer interface 
subsystem and said first inventory subsystem, said first delivery subsystem being 
configured or designed to receive items relating to at least one fulfilled customer 
25 order, said first delivery subsystem further being configured or designed to facilitate 
delivery of said received items to said at least one customer, 

a second business unit for servicing a second plurality of customers associated 
with a second geographic area, the second business unit comprising: 

a second inventory subsystem comprising memory, said second inventory 
30 subsystem including an inventory database configured or designed to maintain 
inventory records of a plurality of items of merchandise; 

a second customer interface subsystem in comrnunication with the second 
inventory subsystem, said second customer interface subsystem being configured or 
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each of the business units to its respective customers. 


56. The system as recited in any of chums 55 wherein said central 
management umt comprises a pushing subsystem in communication each of said 

subsystem being configured or designed to manage catalog data associated with 
merchandise items available to each of the business units. 

25 57. The system as recited in any of claims 56 wherein: 

the first business unit is associated with a first on-line store which services 
said first plurality of customers; 

the second business unit is associated with a second on-line store which 
services said second plurality of customers; and wherein 
30 said central management unit further comprises a catalog database in 

communication each of the online stores, said catalog database including store catalog 
information, fading a first store catalog of merchandise item, associated with me 
first on-line store, andasecond store catalog of merchandise items associated with the 
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58. The system as recited in any of claims 55-57 further comprising a 
headquarters business unit for managing the central management unit, and for 

5 managing business operations relating to each of the business units. 

59. The system as recited in claim 57 wherein said central management 
unit further comprises a central customer data center for storing customer account 
information relating to a plurality of customers, including said first and second 

10 plurality of customers. 

60. The system as recited in claim 59 wherein each of said on-line stores is 
configured to access customer account data from the customer data center. 

15 61 - Thesystemas recited in any ofclaims 59-60 further including: 

a plurality of servers in communication with each of the business units and the 
central management unit for hosting each of the on-line stores via the data network; 

said plurality of servers including at least one interface for enabling an affiliate 
to host an affiliate on-store; 

said system being further configured or designed to enable at least one 
selected business unit to service customers shopping at said affiliate on-line store. 


20 


62. The system as recited in claim 61 wherein the system is further 
configured or designed to route a particular customer to an appropriate business unit 

25 based upon a geographic location associated with the particular customer. 

63. An integrated architecture system for effecting electronic commerce 
via a data network, comprising: 

a customer interface subsystem for presenting representations of selected ones 
of a plurality of products to customers via the data network, and enabling the 
customers to generate orders for subsets of the selected products via the data network; 

an inventory subsystem, in communication with the customer interface 
subsystem, for maintaining and controlling inventory data relating to products 


30 


71 


WO 00/68859 

FCT/USOO/13038 

presented to the customers; 

S ub^fe, pioceBi ^ (lflIle(lnlmv|i|li(>(teiMnroik; "»y 

- «*r ^ ^ fc ^ ^ ~ 

•^Wation voices vulhedaumtrajt; 


10 


data £ * A ^ effeCUng e,CC,r0niC C0 — ~ * a d «* network, the 
1:7° ;° mPriSin8 8 » for facilitating ordering 

subs^tcm for managmg custoiner ordei8| ^ for 
15 mventory data; an order Mfi.ln.ent subsystem for facilitating fulfil of custom 
orders; and a delivery subsystem for ladling delivery customer orders to 
customers, said method comprising: 

receding a customer order at the customer interface subsystem, the customer 
order mcludmg information relating to at leas, one ordered item, and including 
20 •'rfonnauonrelatmgtoaspecifieddeuveiywindownme; 

sending information relating to the customer order to th e order figment 
subsystem after a predetermined cutoff time has passed; 

fulfilling at .east a portion of the customer o'rder at the order fulfillment 
subsystem, said filing including ^ each 

25 successfully filled and processed for shipment to the customer; 
delivering the fulfilled order to the customer, and 
generating updated billing data relating to customer service transactions 
processed during delivery of the order to the customer. 

30 65. The method as recited in claim 64 further comprising allowing the 

custom. t0 raodily we customw ^ ^ ^ ^ ^ ^ 

time has passed. 
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66. The method as recited in any of claims 64-65 further comprising 
allowing the customer to modify the customer order during delivery of the order to the 
customer. 


10 


67. The method as recited in any of claims 64-66 further comprising 
processing, using a mobile field device (MFD), customer service transactions at a 
time of delivery of the order to the customer, said MFD being configured or designed 
to store said updated billing data. 

68. The method as recited in claim 67 wherein said processing of customer 
service transactions include processing a customer return at a customer site. 


69. The method as recited in any of claims 67-68 wherein said processing 
of customer service transactions includes processing an order adjustment at a 

IS customer site. 

70. The method as recited in any of claims 67-69 wherein said processing 
of customer service transactions includes creating a record of each ordered item 
received by the customer. 

20 

71. The method as recited in any of claims 67-70 further comprising 
billing the customer after delivery of the order to the customer for an amount related 
to the updated billing data. 

25 72. The method as recited in any of claims 64-71 fiirmer including: 

generating a vendor purchase order for at least one item of merchandise; 
automatically issuing an expected receipt to the order fulfillment subsystem in 
response to the generation of the vendor purchase order, said expected receipt 
including information about the purchase order, and 
30 updating availability and price information for items associated with the 

purchase order. 

73. The method as recited in claim 72 wherein said updating comprises: 
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Elating updated availability and price information for items associated 
with the purchase order, and associated 

interfJT^ " » *e custom 

. ttlT - " b3SCd ^ ^ " CU,atCd ^ — * - price 

comp^: * ^ 85 ^ ^ ^ " ^ - — 

receiving a vendor shipment associated with the vendor purchase order 
processing received items from the vendor shipment; 
generating expected receipt conformation information in response to the at 
least one received item being processed; and 

updating the availably information relating to received items using the 
expected receipt confirmation information. 

75. The method as recited in any of claims 72-74, said method further 
compnsmg automatically informing at least one vendor of the generated purchase 

20 76. The method as recited in any of claim, 65-75 further comprising 

sending finalized customer order information to said order fulfillment subsystem after 
said pre-determined cutoff time has passed. 

25 provdmg a central publishing subsystem for managing catalog data associated 
with each item of merchandise. 

78 The method as recited in claim 77 nirmer comprising managing, using 
the pubhsmng subsystem, informaUon content presented by the customer interface 
30 subsystem to the at least one customer. 

79. The method as recited in any of claims 77-78 further comprising 
recemng SKU information at the publishing subsystem; 
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automatically processing the received SKU information to thereby generate 
catalog data and processed SKU data; 

publishing the catalog data to the customer interface subsystem; and 
publishing the processed SKU data to the inventory subsystem 

5 

80. Tlie method as recited ' in claim 79 wherein the received SKU 
information is obtained front a content provider. 


81. The method as recited in any of claims 79-80 wherein the received 
1 0 SKU information is obtained from a merchant. 

82. The method as recited in any of claims 79-81 further comprising 
automatically updating a store catalog associated with the customer interface 
subsystem using the published catalog data. 


15 


83. The method as recited in any of claims 79-82 further comprising using 
at least a portion of the catalog data to display information content to the at least one 
customer. 


84. The method as recited in claim 83 further comprising regulating the 
content of information displayed to the at least one customer based upon inventory 
availability data. 


85. The method as recited in any of claims 64-84, wherein the interface 
subsystem further comprises a storefront inventory database, and wherein the method 
further comprises storing catalog data, item availability data, and item price data on 
said storefront database. 

86. The method as recited in claim 85 further comprising generating 
available-to-promise (ATP) inventory data for an item using said item availability 
data, said ATP data corresponding to items of inventory which are available to 
promise for delivery to customers on a specified delivery date. 
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87. ^^thodasrecitedinclaimsefurthercomprisingauto^^ 
5 88. The method as recited in any of claim* »< b-» 

». H* method „ recited in my of claim> ,s^, ft^ ^ . 

90. Tlie method as recited » my of chilm 
^~^eo m pn M ..re» m e^ datlteefor ^ 

•V* d«, tah*, , v ^„ ^ ^ ^ fc ^ ^ 

T T" " ,WC " y ** * "* H "" ,,,em ' compdsi^ 
-«M *~ of custome, ^ lt , fc. „ f ^ ^ ^ ^ ^ 

20 

91. The method as recited in claim 90 wherein said method further 
comprising automatically updating said resource capacity data at respective, pre- 
determined intervals using data from each of said subsystems. 

« 92. The method as recited in any of claims 90-91 further comprising 

reserving a respective amount of resource capacity in said resource capacity database 
for selected subsystems in response to an item being selected for purchase by a 

customer. J 

30 93. The method as recited in claim 92 further comprising automatically 

momfymg the reserved resource capacity associated with at least one ordered item in 
response to a customer modifying a desired quantity of the a , least one item 
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94. The method as recited in any of. claims 92-93 further comprising 
automatically modifying the reserved resource capacity associated with at least one 
ordered item in response to a customer modifying a delivery date associated with the 
at least one item; 


95. The method as recited in claim 93 further comprising freeing the 
reserved resource capacity associated with an ordered item when the customer cancels 
an associated order for the at least one ordered item. 

10 96. The method as recited in any of claims 85-95 further comprising using 

availability data to indicate to the at least one customer which inventory items are 
available for purchase, and when each of said available items can be delivered to the 
at least one customer. 

15 97 - The method as recited in any of claims 64-96 further comprising 

determining whether delivery service is available to a selected customer based upon 
the customer's delivery address. 

98. The method as recited in claim 97 wherein the determination of 
20 delivery service availability to the selected customer is not based upon a zip code 

associated with the delivery address of the customer. 

99. The method as recited in any of claims 67-98 further comprising: 
receiving at a customer site at least one returned item from a customer, and 

25 immediately processing a returns transaction relating to the at least one 

returned item using the MFD. 

100. The method as recited in claim 99 wherein the returned item is 
received by a delivery courier. 


30 


101. The method as recited in any of claims 67-100 further comprising 
presenting a modified receipt to the customer, the modified receipt having a total 
amount to be billed which automatically accounts for any billing adjustments related 
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to the processed customer service transactions. 

102. The method as recited in any 0 f claims 64-. 01 firither comprising 
Mlmg a customer only for order items which have been confirmed as havin Z 

5 received by Die customer. 8 Meo 

103. ^^»^«m ) .f^ m!MK , ammi ^ 

*«- *-Nr*rfc«*,l»b»« wlll , fc mmmit ^ k 

m =mo n , tbi „e 1 ,„ tllecU!ton , erMmspondslosi . ^ *— 
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104. The method as recited in any of claims 64-102 further comprising- 
receiving at the order fulfillment subsystem finalired customer order 

information relating to at least one customer order, 
fulfilling the at least one customer order, 

processing said fulfilled customer order for shipment to a customen and 
generatmg customer order confirmation data after the fulfilled customer order 
has been shipped to the customer. 

105. The method as recited in any of claims 64-103 further comprising- 
receiving at the order fulfillment subsystem expected returns data related to 

processed customer return transactions; 

receiving at least one returned item at the order fulfillment subsystem- 
processing the at least one returned item at the order fulfilment subsystem- 

and ' 

generating returned item confirmation data after the at least one returned item 
has been processed at the order fulfillment subsystem. 


106. The method as recited in claim 105 further comprising updating item 
availability data relating to the at least one returned item using the returned item 

30 confirmation data. 

107. A method for effecting electronic commerce using the system as 
recited in any of claims 1, said method comprising: 


78 


WO00/6W9 fCtnmam 

receiving a customer order at the customer interface subsystem, the customer 
order including information relating to at least one ordered item, and including 
information relating to a specified delivery window time; 

sending information relating to the customer order to the order fulfillment 
5 subsystem after a pre-determined cutoff time has passed; 

fulfilling at least a portion of the customer order at the order fulfillment 
subsystem, said fulfilling including verifying each inventory item which has been 
successfully fulfilled and processed for shipment to the customer, 

delivering the fulfilled order to the customer, 

generating updated billing data relating to customer service transactions 
processed during delivery of the order; and 

billing the customer after delivery of the order for an amount relating to the 
updated billing data. 


15 108. The method as recited in claim 107 further comprising allowing the 

customer to modify the customer order at any time before said pre-determined cutoff 
time has passed. * 
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109. The method as recited in any of claims 107-108 further comprising 
20 allowing the customer to modify the customer order during delivery of the order to the 
customer. 


110. The method as recited in any of claims 107-109 further comprising 
processing, using a mobile field device (MFD), customer service transactions at a 
time of delivery of the order to the customer, said MFD being configured or designed 
to store said updated billing data. 

111. The method as recited in claim 110 wherein said processing of 
customer service transactions include processing a customer return at a customer site. 

112. The method as recited in any of claims 110-111 wherein said 
processing of customer service transactions includes processing an order adjustment 
at a customer site. 
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113 Tht method as w i.ed ta of cMro lmu ^ 
of customer semee ^ ^ , ^ 

item received by the customer. 

..... ^ emethodM ^ « any of claims 110-113 further comprising 

to the updated billing data. 
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